Transactive control framework and toolkit functions

ABSTRACT

Disclosed herein are representative embodiments of methods, apparatus, and systems for facilitating operation and control of a resource distribution system (such as a power grid). For example, embodiments of the disclosed technology can be used to improve the resiliency of a power grid and to allow for improved consumption of renewable resources. Further, certain implementations facilitate a degree of decentralized operations not available elsewhere.

CROSS REFERENCE TO RELATED APPLICATION

This application is a divisional of U.S. application Ser. No.14/108,078, filed on Dec. 16, 2013, now U.S. Pat. No. 10,740,775, whichclaims the benefit of U.S. Provisional Application 61/737,726 filed onDec. 14, 2012, and entitled “TRANSACTIVE CONTROL FRAMEWORK AND TOOLKITFUNCTIONS”, both of which are hereby incorporated herein by reference.

ACKNOWLEDGMENT OF GOVERNMENT SUPPORT

This invention was made with government support under DE-OE0000190awarded by the Department of Energy. The government has certain rightsin the invention.

FIELD

This application relates generally to the field of power grid managementand control.

SUMMARY

Disclosed below are representative embodiments of methods, apparatus,and systems for facilitating operation and control of a resourcedistribution system (such as a power grid). For example, embodiments ofthe disclosed technology can be used to improve the resiliency of apower grid and to allow for improved consumption of renewable resources.Further, certain implementations facilitate a degree of decentralizedoperations not available elsewhere.

“Transactive control and coordination” features market-like mechanismsfor the selection of resources and demand-side assets in an electricpower grid. The disclosed technology concerns new embodiments oftransactive control and coordination. Such embodiments allow fortransactive control and coordination where: (1) the system isimplemented over large geographic areas; (2) the system is implementedacross multiple grid regulation and/or business boundaries; (3) a largediversity of participating resources and loads are to be coordinated;and/or (4) the system desirably functions at multiple scales (e.g., bothlarge areas of the transmission region and at individual devices).

Locations on the electric power grid that perform one or more of thedisclosed techniques of are sometimes referred to herein as “transactivenodes.” Further, embodiments of the disclosed technology are describedin terms of an “algorithmic framework,” where the highest-levelresponsibilities that are to be conducted at a transactive node arediscussed. In certain embodiments, two functional blocks within thealgorithmic framework allow for the further incorporation of (1)“toolkit resource functions” and/or (2) “toolkit load functions.” Forexample, depending on the unique features extant at a given transactivenode (e.g., certain types of generation resources, inelastic electricalloads, other loads that might be responsive to a price-like signal in ademand-responsive way), one or more toolkit functions and their uniquefunctionality may be incorporated. These toolkit functions canrespectively modify the formulation of the price-like signal by theframework, or modify the amount of load that is to be generated orconsumed by assets at this grid location. The functions can also advisethe control of responsive assets.

Embodiments of the disclosed technology can be used to realize the fullydistributed coordination of electrical power grids. In certainembodiments, such coordination can be accomplished by having nearestcircuit neighbors exchange transactive signals. Desirably, these signalsinclude not only price and quantity signals for an imminent timeinterval, but also predicted signals for future time intervals. Incertain implementations, at least two subclasses of transactive signalare used—one price-like and the other representing power. Thetransactive signal that represents power (the TFS) is usefullyaggregated where the power is also combined in a circuit and representsthe power flow between circuit neighbors; a price-like signal (the TIS)may fairly represent costs of multiple resources and incentives if suchcosts are proportionately added where the resources are injected intoand where the incentives occur in the electrical circuit.

In certain implementations, and in contrast to system utilizing explicitbilateral markets, some of the disclosed systems use planned energyconsumption as the feedback.

Also disclosed herein are tools and techniques for computing distributedrelative power flow. For example, a distributed relative power flowmethod is formulated for electrical power systems. In certainembodiments, a node is allowed to allocate its generation or loadchanges among the power flows with its neighbors without the globalknowledge of the power system. Further, in some embodiments, decisionsare made independently at distributed locations to respond to incentivesignals from distributed transactive control. The impacts of thesedecisions on power flow are desirably predicted, which is presentlychallenging to do with conventional power flow formulations. In certainembodiments, parallel computation is an inherent feature of thedisclosed formulation.

Conventional power flow solvers, usually located at a central location,rely on the global knowledge of the power system to predict the impactsof generation or load changes on the power flow. However, it ischallenging to predict the power flow by using such solvers atdistributed locations, where only information from neighbor nodes may beavailable. This is not the case with embodiments of the discloseddistributed relative power flow formulations.

Embodiments of the disclosed power flow formulation can be used in avariety of environments. For example, such implementations can be usedas part of a “smart grid” system, which heavily relies on two-waycommunication and transactive control.

Decisions to respond to incentive signals from transactive control causepower flow changes, which can be predicted in parallel at distributedlocations, without knowledge of the entire power system.

Details of exemplary non-limiting embodiments of the disclosedtechnology are disclosed and illustrated in the sections below. Any oneor more of the features, aspects, and/or functions described in any ofthe sections below or above can be used alone or in any combination orsub-combination with one another.

Embodiments of the disclosed methods can be performed using computinghardware, such as a computer processor or an integrated circuit. Forexample, embodiments of the disclosed methods can be performed bysoftware stored on one or more non-transitory computer-readable media(e.g., one or more optical media discs, volatile memory components (suchas DRAM or SRAM), or nonvolatile memory or storage components (such ashard drives)). Such software can be executed on a single computer or ona networked computer (e.g., via the Internet, a wide-area network, alocal-area network, a client-server network, a cloud-based network, orother such network). Embodiments of the disclosed methods can also beperformed by specialized computing hardware (e.g., one or moreapplication specific integrated circuits (“ASICs”) or programmable logicdevices (such as field programmable gate arrays (“FPGAs”)) configured toperform any of the disclosed methods). Additionally, any intermediate orfinal result created or modified using any of the disclosed methods canbe stored on a non-transitory storage medium (e.g., one or more opticalmedia discs, volatile memory or storage components (such as DRAM orSRAM), or nonvolatile memory or storage components (such as harddrives)) and are considered to be within the scope of this disclosure.Furthermore, any of the software embodiments (comprising, for example,computer-executable instructions which when executed by a computer causethe computer to perform any of the disclosed methods), intermediateresults, or final results created or modified by the disclosed methodscan be transmitted, received, or accessed through a suitablecommunication means.

The foregoing and other objects, features, and advantages of theinvention will become more apparent from the following detaileddescription, which proceeds with reference to the accompanying figures.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a generalized example of a suitable computing hardwareenvironment for a computing device with which several of the describedembodiments can be implemented.

FIG. 2 is a block diagram illustrating the transactive control concept.

FIG. 3 is an illustration of the node-by-node changes to a transactiveincentive signal as it flows from generation to end-use.

FIG. 4 illustrates the dynamics of an electric vehicle charging exampleof the disclosed technology.

FIG. 5 illustrates a simple topology for wind availability as will beused to illustrate an embodiment of the disclosed technology.

FIG. 6 is a representation of toolkit functions for bulk power resources

FIG. 7 is a graph showing the power generated at the transactive noderepresented by FIG. 5 over time.

FIG. 8 is a graph illustrating the unit costs of power for the currenttransactive control example.

FIG. 9 is a graph that presents the hourly resource costs for wind poweraccording to a conventional approach versus a transactive controlapproach.

FIG. 10 is a graph that shows the cumulative cost comparison for atransactive control approach versus a conventional approach.

FIG. 11 is a graph illustrating an example transactive incentive signalas it is affected by a wind power resource.

FIG. 12 is a skeleton diagram of the algorithmic framework at atransactive node.

FIG. 13 is a block diagram illustrating the example timing model.

FIG. 14 is a diagram exemplifying the stacked component resource andincentive costs that compose a transactive signal.

FIG. 15 is another diagram showing an example skeleton model of astandard transactive node that emphasizes the relationship between anexemplary overall methodology and the toolkit functions.

FIG. 16 is a diagram illustrating one view of how multiscale intervalscould be addressed by embodiments of the transactive system.

FIG. 17 is a simple view of the responsibilities of a transactive node.

FIG. 18 illustrates a basic transactive node model.

FIG. 19 illustrates the constraint function transactive node component.

FIG. 20 illustrates the load function transactive node component.

FIG. 21 is a graph showing conceptual responses of methods to variationof an incentive signal.

FIG. 22 illustrates a supply function node component.

FIG. 23 illustrates a general transactive node.

FIG. 24 is a flowchart illustrating an exemplary method for operating atransactive node according to certain embodiments of the disclosedtechnology.

FIG. 25 is another flowchart illustrating an exemplary method foroperating a transactive node according to certain embodiments of thedisclosed technology.

FIG. 26 is another flowchart illustrating an exemplary method foroperating a transactive node according to certain embodiments of thedisclosed technology.

FIG. 27 is another flowchart illustrating an exemplary method forselecting a specific toolkit function from among a library of suchtoolkit functions.

FIG. 28 illustrates the structure of numbered attributes at an exemplarytransactive node.

FIG. 29 shows an example state diagram for a transactive node.

FIG. 30 is an exemplary connection state diagram that applies totransactive neighbors, system managers, assets, and local information.

FIG. 31 is a diagram that illustrates TIS and TFS generation beingdecoupled.

FIG. 32 is a diagram that illustrates TIS processing as may occur forsome embodiments.

FIG. 33 is a diagram illustrating an example where a perpetual exchangeof signals might become sustained between two transactive node neighbors

FIG. 34 is a graph showing weighting factors for a set of demonstrationintervals (IST₀=0:00) using three different values of constant γ

FIG. 35 is a flowchart showing an example toolkit framework of functionsand processes at a transactive node.

FIG. 36 is a flowchart illustrating an exemplary “receive transactiveincentive signal” process.

FIG. 37 is a flowchart for an exemplary “calculate new transactivesignal intervals” process.

FIG. 38 is a flowchart illustrating an exemplary “formulate TIS”process.

FIG. 39 is a flowchart of an exemplary “formulate TFS” process.

FIG. 40 is a flowchart of an exemplary “sum total predicted load”process.

FIG. 41 is a flowchart of an exemplary “calculate applicable toolkitload functions” process

FIG. 42 is a flowchart of an exemplary “send transactive signals”process.

FIG. 43 is a flowchart of an exemplary “calculate applicable toolkitresource and incentive functions” process.

FIG. 44 is a flowchart of an exemplary “control responsive assetsystems” process.

FIG. 45 is a flowchart of an exemplary “sum total predicted resources”process.

FIG. 46 is a flowchart of an exemplary “control responsive resource”process.

FIG. 47 is a set of graphs showing predicted load {circumflex over (P)}compared to measured load P for an example function.

FIG. 48 is a set of graphs that show the linear least-squares error fitfor each hour of the day, for day 4 given the measured data for anexample function.

FIG. 49 is a set of graphs that show the linear least-squares error fitfor each hour of the day, for day 12 given the measured data for anexample function.

FIG. 50 is a set of graphs that show the linear least-squares error fitfor each hour of the day, for day 14 given the measured data for anexample function.

FIG. 51 is a set of graphs showing predicted load {circumflex over (P)}compared to measured load P for an example function.

FIG. 52 is a set of graphs that show the linear least-squares error fitfor each hour of the day, for day 4 given the measured data for anexample function.

FIG. 53 is a set of graphs that show the linear least-squares error fitfor each hour of the day, for day 12 given the measured data for anexample function.

FIG. 54 is a set of graphs that show the linear least-squares error fitfor each hour of the day, for day 14 given the measured data for anexample function.

FIG. 55 is a graph of power vs. wind speed for wind turbines for anexample function.

FIG. 56 is a graph of a hypothetical supply stack.

FIG. 57 is a diagram showing a sample daily DowJones Mid-C hourly index.

FIG. 58 is a plot of exemplary overall cost of energy for hydropower foreach season for an example function.

FIG. 59 shows example graphs for DIST(TIS₀) and ϕ(TIS₀).

FIG. 60 is a graph showing a typical water heater power consumptionduring week and weekend days.

FIG. 61 is an example profile of P_(S)(t).

FIG. 62 is a plot of a winter profile of T_(OSP)(t) that uses the winterparameters.

FIG. 63 is a plot of a summer profile of T_(OSP)(t) that uses the summerparameters.

FIG. 64 is a graph of the predicted electrical power consumption for1000 thermostatically controlled residential buildings where T_(o)=10°C.

FIG. 65 is a graph of the predicted electrical power consumption for1000 thermostatically controlled residential buildings where T_(o)=0° C.

FIG. 66 is a graph of the predicted electrical power consumption for1000 thermostatically controlled residential buildings where T_(o)=0°C.; ΔT_(DRSP)=−2° C. from 8:00 to 10:00 am.

FIG. 67 is a graph of the predicted electrical power consumption for1000 thermostatically controlled residential buildings where T_(o)=0°C.; K_(DRP)=0.75 from 8:00 to 10:00 am.

FIG. 68 is a plot showing results of simulating MATLAB code with oneresponse level.

FIG. 69 is another plot showing results of simulating MATLAB code withone response level.

FIG. 70 is another plot showing results of simulating MATLAB code withone response level.

FIG. 71 is another plot showing results of simulating MATLAB code withone response level.

FIG. 72 is another plot showing results of simulating MATLAB code withone response level.

FIG. 73 is a plot showing results of simulating MATLAB code with tworesponse levels.

FIG. 74 is another plot showing results of simulating MATLAB code withtwo response levels.

FIG. 75 is another plot showing results of simulating MATLAB code withtwo response levels.

FIG. 76 is another plot showing results of simulating MATLAB code withtwo response levels.

FIG. 77 is another plot showing results of simulating MATLAB code withtwo response levels.

FIG. 78 is an example plot of a lighting load.

FIG. 79 is an example plot of a refrigerator load.

FIG. 80 is an example plot of a cooking range load.

FIG. 81 is an example plot of a dishwasher load.

FIG. 82 is an example plot of a clothes washer load.

FIG. 83 is an example plot of a clothes dryer load.

FIG. 84 is an example plot of a miscellaneous electric load.

FIG. 85 is a block diagram showing an example model of ramp up and rampdown periods.

FIG. 86 is a block diagram of an example block input/output functionmodel.

FIG. 87 is a set of plots for DIST(TIS₀) and ϕ(b).

FIG. 88 is an illustration of TOU voltage control concurrent withshedding water heaters.

FIG. 89 is a series of plots that show possible scenarios for changes ingeneration during one interval.

FIG. 90 is an infrastructure cost control diagram.

FIG. 91 shows a graph illustrating the improvement of uninitializedinfrastructure cost estimate for different α parameter selectionsassuming 5-minute update intervals.

FIG. 92 shows a graph illustrating the uninitialized correction of TISover time for different α parameter selections assuming 5-minute updateintervals.

FIG. 93 is a diagram of an exemplary block input/output function model.

FIG. 94 is a graph illustrating an example for one iteration at a giventime.

FIG. 95 is a diagram that shows the specified strategy during a month.

FIG. 96 is a graph illustrating power operations concepts.

FIG. 97 is a diagram of an exemplary block input/output function model.

FIG. 98 is a first diagram illustrating an example power flowcomputation.

FIG. 99 is a second diagram illustrating an example power flowcomputation.

FIG. 100 is a third diagram illustrating an example power flowcomputation.

FIG. 101 is table illustrating an interpretation of a recommendedadvisory signal.

DETAILED DESCRIPTION 1 General Considerations

Disclosed below are representative embodiments of methods, apparatus,and systems for facilitating operation and control of a resourcedistribution system (such as a power grid). The disclosed methods,apparatus, and systems should not be construed as limiting in any way.Instead, the present disclosure is directed toward all novel andnonobvious features and aspects of the various disclosed embodiments,alone and in various combinations and subcombinations with one another.Furthermore, any one or more features or aspects of the disclosedembodiments can be used in various combinations and subcombinations withone another. The disclosed methods, apparatus, and systems are notlimited to any specific aspect or feature or combination thereof, nor dothe disclosed embodiments require that any one or more specificadvantages be present or problems be solved.

Although the operations of some of the disclosed methods are describedin a particular, sequential order for convenient presentation, it shouldbe understood that this manner of description encompasses rearrangement,unless a particular ordering is required by specific language set forthbelow. For example, operations described sequentially may in some casesbe rearranged or performed concurrently. Moreover, for the sake ofsimplicity, the attached figures may not show the various ways in whichthe disclosed methods can be used in conjunction with other methods.Additionally, the description sometimes uses terms like “determine” and“generate” to describe the disclosed methods. These terms are high-levelabstractions of the actual operations that are performed. The actualoperations that correspond to these terms may vary depending on theparticular implementation and are readily discernible by one of ordinaryskill in the art. Furthermore, as used herein, the term “and/or” meansany one item or combination of items in the phrase.

Any of the disclosed methods can be implemented usingcomputer-executable instructions stored on one or more computer-readablemedia (e.g., non-transitory computer-readable media, such as one or moreoptical media discs, volatile memory components (such as DRAM or SRAM),or nonvolatile memory components (such as hard drives)) and executed bya processor in a computing device (e.g., a computer, such as anycommercially available computer). Any of the computer-executableinstructions for implementing the disclosed techniques as well as anyintermediate or final data created and used during implementation of thedisclosed systems can be stored on one or more computer-readable media(e.g., non-transitory computer-readable media). The computer-executableinstructions can be part of, for example, a dedicated softwareapplication or as part of a software agent's transport payload that isaccessed or downloaded via a network (e.g., a local-area network, awide-area network, a client-server network, or other such network).

Such software can be executed on a single computer (e.g., a computerembedded in or electrically coupled to a sensor, controller, or otherdevice in the power grid) or in a network environment. For example, thesoftware can be executed by a computer embedded in or communicativelycoupled to a sensor for measuring electrical parameters of a power lineor electrical device, a synchrophasor sensor, a smart meter, a controlunit for a home or household appliance or system (e.g., anair-conditioning unit; heating unit; heating, ventilation, and airconditioning (“HVAC”) system; hot water heater; refrigerator; dishwasher; washing machine; dryer; oven; microwave oven; pump; homelighting system; electrical charger; electric vehicle charger; homeelectrical system; or any other electrical system having variableperformance states), a control unit for a distributed generator (e.g.,photovoltaic arrays, wind turbines, or electric battery chargingsystems), a control unit for controlling the distribution or generationof power along the power grid (e.g., a transformer, switch, circuitbreaker, generator, resource provider, or any other device on the powergrid configured to perform a control action), and the like. Further, anyof the control units can also include or receive information from one ormore sensors. Any of the transactive nodes described herein can beformed by such sensors, meters, control units, and/or other such units.

For clarity, only certain selected aspects of the software-basedembodiments are described. Other details that are well known in the artare omitted. For example, it should be understood that thesoftware-based embodiments are not limited to any specific computerlanguage or program. For instance, embodiments of the disclosedtechnology can be implemented by software written in C++, Java, Perl,JavaScript, Adobe Flash, Python, JINI, .NET, Lua or any other suitableprogramming language. Likewise, embodiments of the disclosed technologyare not limited to any particular computer or type of hardware. Detailsof suitable computers and hardware are well known and need not be setforth in detail in this disclosure. Furthermore, any of thesoftware-based embodiments (comprising, for example, computer-executableinstructions which when executed by a computer cause the computer toperform any of the disclosed methods) can be uploaded, downloaded, orremotely accessed through a suitable communication means. Such suitablecommunication means include, for example, the Internet, the World WideWeb, an intranet, software applications, cable (including fiber opticcable), magnetic communications, electromagnetic communications(including RF, microwave, and infrared communications), electroniccommunications, or other such communication means.

The disclosed methods can also be implemented by specialized computinghardware that is configured to perform any of the disclosed methods. Forexample, the disclosed methods can be implemented by a computing devicecomprising an integrated circuit (e.g., an application specificintegrated circuit (“ASIC”) or programmable logic device (“PLD”), suchas a field programmable gate array (“FPGA”)). The integrated circuit orspecialized computing hardware can be embedded in or directly coupled toa sensor, control unit, or other device in the power grid. For example,the integrated circuit can be embedded in or otherwise coupled to asynchrophasor sensor, smart meter, control unit for a home or householdappliance or system, a control unit for a distributed generator, acontrol unit for controlling power distribution on the grid, or othersuch device.

FIG. 1 illustrates a generalized example of a suitable computinghardware environment 100 for a computing device with which several ofthe described embodiments can be implemented. For example, any of thetransactive nodes disclosed herein can be implemented by a computinghardware environment, such computing environment 100. The computingenvironment 100 is not intended to suggest any limitation as to thescope of use or functionality of the disclosed technology, as thetechniques and tools described herein can be implemented in diversegeneral-purpose or special-purpose environments that have computinghardware.

With reference to FIG. 1, the computing environment 100 includes atleast one processing unit 110 and memory 120. In FIG. 1, this most basicconfiguration 130 is included within a dashed line. The processing unit110 executes computer-executable instructions. In a multi-processingsystem, multiple processing units execute computer-executableinstructions to increase processing power. The memory 120 may bevolatile memory (e.g., registers, cache, RAM), non-volatile memory(e.g., ROM, EEPROM, flash memory), or some combination of the two. Thememory 120 stores software 180 for implementing one or more of thedescribed techniques for operating or using the disclosed systems. Forexample, the memory 120 can store software 180 for implementing any ofthe disclosed techniques.

The computing environment can have additional features. For example, thecomputing environment 100 includes storage 140, one or more inputdevices 150, one or more output devices 160, and one or morecommunication connections 170. An interconnection mechanism (not shown)such as a bus, controller, or network interconnects the components ofthe computing environment 100. Typically, operating system software (notshown) provides an operating environment for other software executing inthe computing environment 100, and coordinates activities of thecomponents of the computing environment 100.

The storage 140 can be removable or non-removable, and includes magneticdisks, magnetic tapes or cassettes, CD-ROMs, DVDs, or any other tangiblestorage medium which can be used to store information in anon-transitory manner and which can be accessed within the computingenvironment 100. The storage 140 can also store instructions for thesoftware 180 implementing any of the described techniques, systems, orenvironments. The input device(s) 150 can be a touch input device suchas a keyboard, mouse, touch screen, pen, or trackball, a voice inputdevice, a scanning device, or another device that provides input to thecomputing environment 100. The output device(s) 160 can be a display,touch screen, printer, speaker, or another device that provides outputfrom the computing environment 100.

The communication connection(s) 170 enable communication over acommunication medium to another computing entity. The communicationmedium conveys information such as computer-executable instructions, anagent transport payload, or other data in a modulated data signal. Amodulated data signal is a signal that has one or more of itscharacteristics set or changed in such a manner as to encode informationin the signal. By way of example, and not limitation, communicationmedia include wired or wireless techniques implemented with anelectrical, optical, RF, infrared, acoustic, or other carrier.

The various methods, systems, and interfaces disclosed herein can bedescribed in the general context of computer-executable instructionsstored on one or more computer-readable media. Computer-readable mediaare any available media that can be accessed within or by a computingenvironment but do not encompass transitory signals or carrier waves. Byway of example, and not limitation, with the computing environment 100,computer-readable media include tangible non-transitorycomputer-readable media, such as memory 120 and storage 140.

The various methods, systems, and interfaces disclosed herein can alsobe described in the general context of computer-executable instructions,such as those included in program modules, being executed in a computingenvironment on a target processor. Generally, program modules includeroutines, programs, libraries, objects, classes, components, datastructures, and the like that perform particular tasks or implementparticular abstract data types. The functionality of the program modulesmay be combined or split between program modules as desired in variousembodiments.

Computer-executable instructions for program modules may be executedwithin a local or distributed computing environment. As noted, thedisclosed technology is implemented at least part using a network ofcomputing devices (e.g., any of the computing device examples describedabove). The network can be implemented at least in part as a Local AreaNetwork (“LAN”) using wired networking (e.g., the Ethernet IEEE standard802.3 or other appropriate standard) or wireless networking (e.g. one ofthe IEEE standards 802.11a, 802.11b, 802.11g, or 802.11n or otherappropriate standard). Furthermore, at least part of the network can bethe Internet or a similar public network.

1.1 Acronyms and Abbreviations

This disclosure sometimes makes reference to the following acronyms:

-   HVAC heating, ventilating and air conditioning-   IST interval start time-   LMP locational marginal price-   RMS root mean square-   TCS transactive coordination system-   TFS transactive feedback signal-   TIS transactive incentive signal-   UTC Coordinated Universal Time

1.2 Terms

This disclosure will sometimes make reference to the following terms,whose non-limiting definitions are provided below. These definitions donot necessarily apply in all instances and may vary depending on thecontext.

advisory control A signal that is transmitted by a transactive node toits local responsive signal asset systems advising these systems tochange their energy consumption or generation asset model A usuallydynamic model of an asset system (e.g., a population of electric waterheaters) that can predict its change in load or change in supply inlight of an event (e.g., a curtailment of the asset system). locationalA unit price of energy that represents the spatial and temporal price ofmarginal price the marginal supply resource. Today, locational marginalprice is calculated centrally. non-transactive Refers to energy that canbe exchanged between transactive nodes of energy a transactivecoordination system and entities that reside outside the boundaries ofthe transactive coordination system relaxation A criterion against whichchanges in subsequent transactive signals are criterion compared. Ifchanges are significant based on this criterion, then new transactivesignals are calculated and published. transactive A distributedsystem-of-systems in which transactive nodes coordinate coordination thebalance between energy resources and loads by communicating systemtransactive signals toolkit function A function that is invoked by thetransactive node object model to represent the unique set of incentives,resources, and loads that are managed at the transactive node. Includestwo subclasses-toolkit resource and incentive functions and toolkit loadfunctions. toolkit load One type of a plurality of toolkit functionsthat calculates load, change in function elastic load, and controlsignals for the specific demand-side assets at a transactive nodetoolkit resource One type of a plurality of toolkit functions thatcalculates incentive costs, and incentive supply energy, and energycosts for the specific incentives and supply function resources at atransactive node. Includes toolkit resource functions and toolkitincentive functions. transactive Energy that is exchanged betweentransactive nodes of a transactive energy coordination systemtransactive One of a plurality of subclasses of transactive signals.Represents feedback signal predicted aggregate power flow between twoneighboring transactive nodes. transactive One of a plurality ofsubclasses of transactive signal. Represents the incentive signaldelivered unit cost of energy at a system location. transactive Adjacenttransactive nodes that exchange energy and are therefore neighborsobligated to exchange transactive signals with one another. This termmay be equivalently stated as neighboring transactive nodes or circuitneighbors. transactive node A node that participates in a transactivecoordination system to send and receive transactive signals transactivenode The formal state model that resides at a transactive node anddefines object model its behaviors, interactions, and interfaces. Thisterm usually refers to the common responsibilities of transactive nodesthat are interoperable, standardized. transactive signal A class ofsignal shared between transactive neighbors

2 Introduction

This section introduces some of the basic concepts of the disclosedtransactive control and coordination technology. FIG. 2 is a blockdiagram illustrating a general system 200 for implementing transactivecontrol. The figure represents a simple electric power system topology200 with power flowing from generation resources on the right throughthe components of the system to loads on the left.

At any point in the topology where one can affect the flow of power,operational objectives may be taken into account. In the transactivecontrol technique of the disclosed technology, these objectives can bemonetized and included in a signal referred to as the “transactiveincentive signal” (TIS). If at a given point, one should reduce loadbelow that point, then the monetization computations will result inaltering (e.g., raising) the value of the TIS. If, on the other hand, itis beneficial to add load below that point, then the computations willalter (e.g., lower) the value of the TIS in the opposite direction. Inother words, by using embodiments of the disclosed transactive system,one can represent operational objectives to responsive elements of thesystem and incentivize them to change their behavior in response to themonetized objectives. In FIG. 2, this is represented by the arrow fromright-to-left labeled “operational objectives.”

The responsive elements of the system also play an active role throughmaking information available about their planned consumption of electricpower. This is represented by the arrow from left-to-right labeled“status and opportunities.” In embodiments of the disclosed technology,information about the future forecast of the plans for generationresources and constraints associated with the flow of power through thesystem interact with temporally aligned information about the plannedbehavior or loads or other responsive resources. Local storage systemsare an example of another type of responsive resource that may bethought of as being a positive, neutral (not consuming), or negativeload.

With this general background, the following additional features of thetransactive control and coordination system will now be introduced.

-   -   Transactive Control: A single, integrated, smart grid incentive        signaling approach utilizing an economic signal as the primary        basis for communicating the desire to change the operational        state of responsive assets.    -   Transactive Incentive Signal (TIS): A representation of the        actual delivered cost of electric energy at a specific system        location (e.g., at a transactive node). Includes both the        current value and a forecast of future values. In certain        embodiments, the current incentive signal value refers to the        value for the imminent (or next-to-occur) interval.    -   Transactive Feedback Signal (TFS): A representation of the net        electric load at a specific system location (e.g., between        neighboring transactive nodes). Includes both the current value        and a forecast of future values. In certain embodiments, the        current value refers to the feedback signal value for the        imminent (or next-to-occur) interval.

2.1 What is a Transactive Control Node?

The basic operational unit of embodiments of the illustrated transactivecontrol technique is the transactive control node. In certainimplementations, the transactive control node responds to systemconditions as represented by incoming Transactive Incentive Signals andTransactive Feedback Signals through (a) incorporation of local assetstatus and other local information; (b) decisions about behavior oflocal assets; and/or (c) updating both transactive incentive andfeedback signals. Inputs are used by the node to compute incentive andfeedback signals. Further, in some embodiments, each signal is asequence of forecasts for a time-series, so inputs will also besequences of future (forecast/planned) values

Transactive control nodes may be implemented any place in the powersystem topology, preferably where it is possible to affect the flow ofpower in the system. This is true in both the bulk power system andcarries through into the distribution system down to the end-use level.For example, embodiments of the disclosed technology can be used in alarge region of the power grid (e.g., a large interconnected region ofthe transmission grid, sometimes referred to as a transmission zone), adistribution utility service territory, or for any other sized region,area, or space (e.g., at the substation level, at the feeder level, at abuilding level, or even at the household level. Transactive controlnodes may be implemented down to the level of individual devices. Onemay also implement transactive control nodes that manage a collection ofdevices as an aggregated responsive asset or asset system.

2.2 An End-to-End View

FIG. 3 is an illustration 300 of the node-by-node changes to atransactive incentive signal (TIS) as it flows from generation toend-use. In particular, FIG. 3 provides a high level end-to-end view ofthe flow of transactive incentive signals through a transactive controland coordination system. In the figure, the TIS begins at a generationresource with the TIS values representing the generation cost. Tosimplify the example, transmission costs are also included so that whenthe signal is received at the utility-level, it represents the full costof power delivered to the utility.

At the utility level, the utility has the opportunity to introduce localinformation and operational objectives. For example, the utility maywish to avoid demand charges associated with peak loads. The financialimpact of peak loads can be used in calculating TIS values toincentivize load shifting.

In the example, there are also renewable generation assets local to theutility. The utility may also incentivize consumption of energy fromthese assets through the TIS. On the right hand side of FIG. 3, one cansee the TIS presented to responsive assets as an aggregation of thecosts to delivery power to the end-uses including generation costs,constraints, and operational objectives.

Missing from this example is the transactive feedback signalrepresenting the behavior of the responsive assets. A feature of certainembodiments of the transactive control technique is that this signal andthe transactive incentive signal are both used at a transactive controlnode to make decisions about the behavior of responsive assetscontrolled at that node or to be incentivized by that node. Thisinteraction between the TIS and TFS takes place based on the forecast ofcost of power delivered and the behavior of responsive assets. Throughthis interaction, a form of closed loop control is achieved. Thedecision logic and algorithmic functions of the transactive control nodeare desirably constructed in such a manner as to have convergence and toavoid oscillation.

2.3 An End-to-End View Via an Illustrative Example

One can better understand this interaction between the TIS and TFSthrough a simple qualitative example. Consider the following scenario.On a distribution feeder, imagine a pole top transformer feeding threehouses. Each home has an electric vehicle. For this example, assume thateach of the vehicle owners will want to fast charge their vehicle. Withthe normal base load for the three houses, all three vehicles fastcharging will overload the pole top transformer.

In this example, the pole top transformer is receiving a TIS fromupstream (presumably from the substation) and a TFS from each of thehouses. The TFS from each house includes information about the plannedcharging activity for the corresponding electric vehicle. Thetransformer desirably makes decisions about whether to change the valueof the TIS based on the current and future load as represented byaggregating the TFS from each house. It also may take into account otherinformation, such as the ambient air temperature, weather forecasts,operating history, and so forth.

The three electric vehicles in this example, EV1, EV2, and EV3, eachhave different charging strategies. EV1 is capable of flexible charging,meaning that the rate of charge can be varied. EV2 charges at any cost.EV3 is a bargain hunter and will schedule charging when cost is low.

For this example, assume the following: EV1 desires to charge at 5 PM,EV2 wishes to charge at 6 PM and EV3 wishes to charge at 7 PM. Assume aswell that there is a typical diurnal load curve for the three housesseen in this example as the combined load at the transformer. Thepole-top transformer has a load rating of 40 kW. As long as the load isbelow 40 kW, the service life of the transformer is not being degraded.If the load is above 40 kW, then the service life of the transformer isreduced depending on factors including the load, the duration of loadabove the 40-kW limit, ambient air temperature and possibly otherfactors. The operating principle for the transformer's update to the TISis a computation in which the monetary impact of load is computed basedon the forecasted duration above the limit and the other factorsmentioned. This computation can be performed with information about thecost to replace the transformer, the rated service life, and if desired,economic factors such as the cost of money. The point is that the impactof overloading the transformer is monetized and the result used tochange the forecast value of the TIS.

The electric vehicle smart chargers may then respond to the change inTIS value (e.g., increased for overloading) and adjust their plansaccordingly. A back and forth exchange, a negotiation if you will, takesplace through the exchange of TIS and TFS updates. When the negotiationsettles, then the “agreed” solution to consumption should be stablebarring other perturbations.

A key challenge in this negotiation is to avoid oscillation. Thealgorithms and decision logic for both the smart charger and thetransformer desirably have appropriate damping factors to drive thenegotiation to a stable, non-oscillatory result. In this simple example,a qualitative result is presented to illustrate the nature of theinteraction.

FIG. 4 illustrates the dynamics of the electric vehicle chargingexample. As described above, EV1 forecasts that it will start chargingat 5 pm (hour 17), EV2 forecasts that it will start charging at 6 pm(hour 18) and EV3 forecasts that it will start charging at 7 pm (hour19). None of the EV smart chargers have knowledge of the plans of theother. Information is communicated via their forecasts sent to thepole-top transformer and the resulting changes in the forecast TISvalue.

In the figure, the broad dashed line represents the forecast total load.Notice that between hours 16 and 17, it simply tracks the normal diurnalload pattern. When the charging plans of the EV's are revealed throughthe TFS sent to the pole-top tranformer's transactive control node theforecast total load remains below the transformer's load limit until thetime that EV2 proposes to start charging. Note that, in this example,all vehicles are proposing a level-2 fast charge initially.

When EV2 proposes to begin charging at hour 18, the forecast total loadgoes above the load limit. The TIS correspondingly increases above theTIS that is associated with the normal diurnal load. EV3's proposal tobegin charging at hour 19 pushes the forecast load even higher. If allthree vehicles are level-2 charging, the load approaches 10 kW above theload limit. With the three proposed charging times revealed, the TIS isadjusted and the vehicles respond. For this example, the result issimplified by showing the final result. In practice several iterationswould typically be used to achieve the final, stable result.

The final result, as illustrated in FIG. 4, shows that EV1 adapts itsplans based on its flexible charging strategy. EV2 does not modify itsplan. Remember this is the vehicle that will charge at any price. EV3,the bargain hunter, chooses to shift charging to a night time hour whenprices are even lower than its original proposal to begin charging athour 19. As seen in the figure, EV1's flexible charging strategy offsetsEV2's charge at any price to maintain the total load just at thetransformer's load limit.

This simple example illustrated the basic principle of the transactivecontrol technique. The technique can be applied at any point in thepower system and can coordinate monetized energy impacts and thebehaviors of responsive loads where such devices and opportunitiesexist. Consider, for example, a battery storage system at a distributionsubstation. The associated transactive control node would be makingdecisions about whether to charge, discharge, or do nothing with thebattery system based on the incoming TISs, the incoming TFSs, localconditions such as the state of the battery system, and updating the TISand TFS it sends to neighboring transactive control nodes accordingly.Transactive control nodes can be deployed throughout the power systemfrom generation resources, through the transmission system, and in thedistribution system down to end uses. The technique can be appliedwithin end use points including residential, commercial and industrialuses to manage the behavior of responsive systems and devices.

2.4 Extended Example

The example above showed the use of the transactive control technique atend-use points within a distribution system. In this section, a furtherexample of the transactive control and coordination system isconsidered. This example further illustrates the use of the technique touse local responsive assets to help facilitate the integration ofintermittent renewable energy resources.

In order to facilitate discussion of this example, first consider theformalization of the transactive control technique. This allows the useof standard way of referring to the functional elements of animplemented transactive control and coordination system.

For embodiments of the disclosed technology, consider a formal model ofthe functionality of transactive control nodes. A transactive controlnode object state model has been defined and is the basis forimplementing a transactive node object model (TNOM). This approach isscalable, algorithmic and supports explicit consideration ofinteroperability through the formal specification of both the syntax andsemantics of the transactive incentive signal and transactive feedbacksignal. The “responsibilities” of a transactive control node summarizedearlier are formally represented in the object model.

For embodiments of the disclosed technology, a standardized approach toimplementation is made possible through the design and implementation ofa “toolkit.” The toolkit includes well-defined interfaces to utilityresponsive asset systems and simple, common algorithms for updatingtransactive signals and determining “control” signals to responsiveasset systems.

In designing the toolkit, functions for resources and loads can bedefined. The resource functions are primarily defined for the bulk powersystem and represent systems that supply power. At the utility level,functions associated with local resources or utility concerns such asavoiding demand charges are defined. Load functions can be defined thatare associated with the different classes of loads or with localresources such as battery storage systems that may have load or resourcebehaviors (which are treated as negative loads.)

In embodiments of the disclosed technology, the resource functionsinclude functions from a wide variety of categories. For example, incertain embodiments, the resource functions include one or more of:

-   -   1. Imported Electrical Energy        -   1.1. Non-transactive imported energy        -   1.2. Transactive imported energy    -   2. Renewable energy resource        -   2.1. Wind energy        -   2.2. Solar energy        -   2.3. Hydropower    -   3. Thermal generation    -   4. General infrastructure cost    -   5. System constraints        -   5.1. Transmission constraints        -   5.2. Equipment and line constraints    -   6. System energy losses        -   6.1. Transmission losses        -   6.2. Distribution losses        -   6.3. Device/component losses    -   7. Demand charges    -   8. Market impacts

In embodiments of the disclosed technology, the load functions includeone or more functions from the following categories: (1) inelastic, (2)elastic with limited numbers of discrete events available, (3) elasticwith daily events available, or (4) elastic with a continuum or nearcontinuum of responses available. There can then exist a matrix of thesefour categories, with specific loads that fit into one or more of thesecategories. For example purposes only, the following is a list ofexample load functions that should not be construed as limiting in anymanner. For instance, load functions can be created for a wide varietyof assets or asset systems that that can be used in embodiments of thedisclosed technology (e.g., for a residence, there may be functions fora variety of different assets and/or asset systems, such as responsivewater heaters, thermostats, clothes dryers, web portals, in-homedisplays, or other such assets and asset systems).

-   -   1. Bulk inelastic load        -   1.1. Bulk commercial load        -   1.2. Bulk industrial load        -   1.3. Bulk residential load        -   1.4. Small wind generator negative load        -   1.5. small-scale distributed generator negative load        -   1.6. Small-scale solar generator negative load    -   2. General event-driven demand response        -   2.1. Commercial        -   2.2. Distribution system voltage control        -   2.3. Residential behavior            -   2.3.1. Portals    -   3. General time-of-use demand response        -   3.1. Battery storage        -   3.2. Commercial        -   3.3. Residential behavioral            -   3.3.1. Portals        -   3.4. Residential        -   3.5. Distribution system voltage control    -   4. General real-time continuum demand response        -   4.1. Battery storage        -   4.2. Commercial        -   4.3. Residential behavioral            -   4.3.1. Portals        -   4.4. Residential

It should be understood that in embodiments of the disclosed technology,a transactive node may host multiple toolkit functions, including anycombination of multiple resource and incentive functions, multiple loadfunctions, or combinations of both resource and incentive and loadfunctions. For instance, the resource and/or incentive functions used ata transactive node will typically depend on the location of thetransactive node in a power grid topology, and on the one or moreresources and/or loads for which the transactive node is responsible.This ability to “mix and match” resource and incentive functions whilestill maintaining a common transactive signal communication structuregives embodiments of the disclosed technology wide flexibility andscalability for implementing a transactive control system.

2.4.1 An Example Using Wind Resources

For this example, consider the following general conditions andobjectives: (a) the predicted transactive incentive signal increaseswhen wind energy decreases and visa versa; (b) the transactive incentivesignal is communicated and mixed between transactive nodes; and/or (c)assets respond to improve consumption of wind when wind energy isavailable or near where wind is available.

For purposes of this example, also consider the simple topology 500illustrated in FIG. 5. In the left hand side of the figure, atransactive control node can be observed with two generation resources.The lower illustration in the figure represents conventional generationsuch as a coal fired power plant. The upper illustration represents windturbines. On the right hand side of the figure, one can see atransactive control node with three types of assets: conventionalresistive load in the form of a water heater, a distributed energyresource in the form of battery storage, and a distribution systemvoltage control system represented by the cartoon with wires and powerpoles. For this example, the two transactive control nodes arecommunicating with each other through the exchange of transactiveincentive signals and transactive feedback signals. Note that thetransactive control node on the left is associated with features of thebulk power system—bulk generation resources—while the transactivecontrol and coordination system on the right is associated with assetsin the distribution system.

Consider now the toolkit load functions associated with the resourcesshown in the left hand side of illustration 600 in FIG. 6, which showsrepresentations of toolkit functions for bulk power resources. Agraphical representation of these toolkit functions is also shown inFIG. 6.

For conventional generation, toolkit resource function #2 shown in FIG.6, the function is a single point representing a fixed cost ofproduction. The vertical access represents cost in $/MWh and thehorizontal axis the power produced. For purposes of this example, assumethat this resource operates at a fixed point ignoring for this exampleramping and any other factors that would cause the power output to vary.

The other example of wind power, toolkit resource function #1, is morecomplicated. In this case, assume a cost of power that is inverselyproportional to the power output of the system. Thus, when there is lowwind and low production the cost per unit of power is high. On the otherhand, when there is high wind and corresponding high power output thecost is low. It should be noted that there are many possible ways toconstruct the resource functions. The underlying question is how toassign cost—to monetize the activity of the resource asset. Inembodiments of the disclosed technology, one should assign cost in a waythat incentivizes desired outcomes. In this example, the resourcefunction defined for the wind resource has lowest cost when there is anabundance of wind power thus incentivizing consumption of wind powerwhen it is available. Another consideration when evaluating potentialresource functions is that candidate resource functions for a givenasset should ensure the same total cost over relatively long periods oftime.

Having defined resource functions allows one to look at their behaviorover time. FIG. 7 is a graph 700 that depicts the power generated attransactive node #1. Base generation is shown as constant at 10 MW. Windgeneration varies from 10 MW for the first 30 hours dropping to zero (0)thereafter.

With this forecast of power production in mind, consider the forecast ofcost of power from these two resources both with current approaches andwith the transactive control approach using embodiments of the resourcesfunctions disclosed herein.

In this example, short-term power trading on spot or even day-aheadmarkets is ignored. In this case, the cost of power will be anaggregated value based on the fixed rate associated with each of the tworesources. From the point of view of today's consumer, the cost of poweris at a fixed rate—thus there is no incentive to change consumptionbehavior associated with the cost of power.

FIG. 8 is a graph 800 illustrating the unit costs of power for thecurrent transactive control example. In this case, the base generationis still provided at a fixed cost as previously shown. The unit cost ofwind power is at a relatively lower cost while the wind is blowing andrises when the wind dies—eventually becoming infinite when wind power isunavailable. The aggregate cost, that seen by consumers, is an average(possibly weighted) of the two representing the incentive to consumewhen wind is available at a cost below normal base generation cost andto not consume when wind is unavailable at a cost above normal basegeneration cost.

Embodiments of the disclosed technology provide a scheme thatincentivizes the desired behavior—preferentially to consume wind power.But what about the long-term cost objective? Let us compare how costsaccumulate over time. FIG. 9 is a graph 900 that presents a comparisonof hourly resource costs with or without transactive control. Given theexamples, the resource function for base generation, the hour cost forthat resource is the same in either case. For the wind resource,however, the hourly cost is quite different. As the system and economicsare currently formulated, the wind resource is only compensated when itis producing power. The rate is fixed and costs should be recoveredbased on an estimate over the long term of the percentage of time theresource will be available. This is represented by the line in FIG. 9that starts at the hourly cost of 100 and then drops to zero (0) at hour31. In contrast, the hourly cost for the wind resource is constant at 40using transactive control. This is because during the period of timewhen wind power is available, loads are incentivized to consume via alower cost (e.g., using the transactive incentive signal) andincentivized to not consume via a higher cost when wind is notavailable. The cost of wind production still should be recovered. Soover the excess cost recovery when wind is not available (as compared tobase generation cost) is used to make the wind producer whole resultingin an apparent fixed hourly cost.

Integrating the hourly costs allows one to check the long-termcriteria—that costs should be the same over the long term fortransactive versus the non-transactive approaches. FIG. 10 is a graph1000 that shows this cumulative cost comparison and shows that thetransactive control technique can be formulated in such a manner as toachieve this objective.

Now that the formulation of toolkit resource functions have beenconsidered, example differences between conventional approaches andembodiments of the transactive approach can be summarized. For instance,the resource functions for generation assets of the disclosed technologycreate a transactive incentive signal as depicted in graph 1100 of FIG.11. The dynamics of the signal are as described above in the discussionof unit costs.

Attention can be shifted to the consumption, or load, side of thecomputation. From a behavioral or responsiveness point of view, loadswill be mixed. Some will be controllable; in other words, the loads willhave the potential to respond to an incentive signal. Still further, insome instances, some loads will also be capable of acting as a load or ageneration resource. For example, a battery system may have eitherbehavior, and decisions about the battery may be made about when tocharge, discharge, and/or at what rates. In this respect, a battery loadmay be highly responsive. For any given class of load assets, one mayconstruct one or more load toolkit functions. These functions desirablytake into account the load functions for other distribution systemassets, and are discussed in more detail below.

Embodiments of the disclosed technology implement a distributed systemfor engaging responsive assets within the power system to manageconstraints and support the integration of elastic energy resource(e.g., wind power and/or other intermittent renewable energy resources).

In particular implementations, the technique primarily uses twosignals—the transactive incentive signal and the transactive feedbacksignal—representing the cost of power delivered to a given point in thesystem and the load at a given point in the system respectively. Inparticular embodiments, both signals are forward forecasts. The use ofthese representations reduces communications capacity requirements butrelies on the development of algorithms for monetizing operationalobjectives. This was illustrated through a simple electric vehiclecharging example and an extended example for wind power integration.

3 Exemplary Embodiments of the Disclosed Transactive Control Signals 3.1Introduction

The transactive control and coordination system (TCS) of the disclosedtechnology can be implemented primarily using two classes of transactivesignals: transactive incentive signals (TIS) and transactive feedbacksignals (TFS). These signals are exchanged between distributed systemsites. The purpose of these signals is to coordinate supply and load inthe near future, from a few minutes to several days out.

Some might compare the TCS with locational marginal pricing (LMP), inwhich energy prices are differentiated by time and by circuit locationto address the economics of resource availability and to help mitigatetransmission system congestion. A TCS shares certain goals with LMP.Like an LMP price signal, a TIS is a price-like signal that mayrepresent the value of energy resources while taking into account thelocation, the time, transmission congestion, and transmission losses.Unlike an LMP signal, however, a transactive signal has been generalizedto represent other additional impacts that can be monetized.Furthermore, a TCS facilitates fully distributed, not centralized,formulations of transactive signals. Because the calculations may befully distributed, a TCS system is scalable throughout transmissionsystems, distribution systems, customer premises, and/or device levels.

An LMP represents the cost of the marginal energy resource and istherefore useful for coordinating the dispatch of energy resources. Animplication is that dispatch decisions for supply-side or demand-sideresources are based solely on comparison against the current marginalresource. By contrast, embodiments of the TIS are preferably formulatedto represent energy cost as a function of time and location so that itmay coordinate multiple supply-side and demand-side resources, not justthe marginal ones. (This distinction is increasingly of interest asmust-run renewable resources become a significant fraction of systemresources. Economic dispatch and marginal energy price are currentlybased largely on fuel expenses. Renewable resources, which consume nofuel, displace fueled resources. Therefore, the marginal price, which isdetermined by the marginal fueled resource, incurs downward pressure. Ifthe resulting marginal price is used to calculate revenues, thenrevenues also experience downward pressure, even though the must-runrenewable resources may have generated relatively expensive energy.) Theeconomic usefulness of many resources is determined during planningstages, not as they operate. Once the resource has been built, it shouldbe called upon anytime it is useful, not only when it competes well withthe current marginal resource.

A TCS and its transactive signals, in principle, may thereby unify somedecision processes that are conventionally addressed separately orsequentially—the using the dispatch of must-run resources and economicdispatch, for example, or the testing of economic power flow againstpermissible constrained power flow.

While quantity of energy is most certainly used during the calculationsof LMP signals, there is seldom a need for those signals to becommunicated outside the location of the central solver. In embodimentsof the disclosed technology, however, the TFS, which represents aquantity of power, accompanies the price-like TIS. For example,distributed formulations can be used with signals that represent boththe paired price and the quantity of power for time intervals. Inparticular, transactive signals can enable the coordination of the TCS,where each transactive node has a responsibility to perform its share ofwhat is presently a very centralized calculation. The standardization ofa TCS and its transactive signals can permit new implementers to join aTCS.

Now that some general characteristics of a TCS have been introduced,largely through a comparison between TCS and LMP systems (see, e.g.,Table 1), further details and qualities of the TCS will be introduced.For example, the sections below describe the component parts of a TCS,including its transactive signals, and how each of the two subclasses oftransactive signal are influenced and formulated.

TABLE 1 Comparison Summary between LMP and TCS LMP TCS Calculation isperformed centrally Calculation may be distributed Signal representsunit price of Signals preferably represent inclusive marginal resourceunit cost of energy and quantity of energy Somewhat scalable to Veryscalable, in principle, disaggregated regions of throughout generation,transmission, generation, transmission, maybe distribution, customer,and end-use into distribution devices Usually relevant only to Mayrepresent perspectives of any perspective of one single system and manysystem component owners operator Contractually engages large May engagemany small, flexible blocks of firm resources resources and large blocksof firm resources alike through the normal course of energy pricing orthrough alternative and diverse incentive mechanisms May includeforecasted future Includes forecasted future intervals intervals

3.2 An Example Transactive Coordination and Control System

An exemplary embodiment of the TCS may be understood by its componentsand their behaviors. In particular implementations, its principalcomponents comprise one or more of the following:

-   -   transactive node—system sites that are active participants in a        TCS. A transactive node hosts a transactive node object model        and exchanges transactive signals with its transactive        neighbors.    -   transactive signal—comprises one or more subclasses of signals        that are exchanged by transactive nodes. For instance, in        particular implementations, the transactive signal comprises two        subclasses that include the TIS and TFS.    -   transactive node object model—the state model of the actions and        responsibilities that are managed by a transactive node    -   toolkit functions—one or more functions that may be called upon        by the transactive node object model to customize it for the        unique set of inelastic and elastic supply and demand-side        resources that are managed at a respective transactive node. The        functions can belong, for example, to a plurality of subclasses.        The subclasses can include, for instance, toolkit resource and        incentive functions and toolkit load functions.

3.3 Example Transactive Node

In embodiments of the disclosed technology, transactive nodes are pointsin the topology of a TCS. In particular embodiments, transactive nodesperiodically exchange transactive signals with their neighbors (e.g.,their nearest neighbors) with which they can exchange electrical energy.For instance, transactive signals are exchanged between neighboringtransactive nodes that share an electrical conductor. (This is true inthe sense that two transactive nodes that exchange power alsocommunicate. The actual pathway and communication media betweentransactive nodes can vary from implementation to implementation.) Theresulting interconnection topology can, in some embodiments, behierarchical. Transactive nodes can be established at any hierarchicalpoint in the topology (e.g., at any point of the utility-side topology,such as a sub-station, feeder, transformer, or the loke) or at any pointof the load-side topology, a feeder, transformer, household controlunit, electric vehicle charger, or any control unit at the household orother load control unit).

3.4 Example Transactive Signals

Transactive signals can be represented as a series of data. Forinstance, in particular implementations, the transactive signals are aseries of triplets. Each triplet is comprised of a time interval, avalue, and a confidence level that qualifies the value. In otherimplementations, the transactive signals comprise a series of valuepairs, where each value pair comprises any combination of a timeinterval, a value, or a confidence level. In still otherimplementations, the transactive signals comprise one or more of a timeinterval, a value, and/or a confidence level. In particularimplementations, there are two subclasses of transactive signals:

-   -   the TIS—a representation of preferably the delivered unit cost        of the energy that is stated in the corresponding TFS. There is        a TIS representation at each transactive node and for each time        interval.    -   the TFS—the power flowing between two transactive nodes during a        given time interval. The unit cost of the energy that is being        exchanged is the corresponding TIS of the given time interval        and for the given transactive node that supplies the energy.        There is a TFS representation for each transactive neighbor at        each transactive node and for each time interval.    -   The examples herein were simplified to address real power and        real energy. However, the reader skilled in the art of        electrical power will understand that the examples could be        extended to refer to real energy (meaning the product of real        power and elapsed time), reactive energy (meaning the product of        reactive power and elapsed time), or both real and reactive        energy components. That is, a TIS may separately or jointly        monetize real energy, reactive energy, or both real and reactive        energies, and a TFS may represent real, reactive, or both the        real and reactive power components of the power flowing between        two transactive nodes.

3.4.1 Predictive Signal Intervals

In particular embodiments, the transactive signals are forecasts. Theforecasts refer to an imminent time interval (e.g., the time intervalthat will start next) and a number of additional future intervalsthereafter. The future intervals are defined by their starting times anddurations. Once stated, an interval remains fixed in time, and a futureinterval moves closer with the passing of time. The intervals in atransactive signal are successive in one particular embodiment of thedisclosed technology (e.g., they do not overlap).

A subsequent transactive signal updates the values and confidence levelsfor many or all of the previous transactive signal's time intervals. Newintervals may also be created to push the forecast even farther into thefuture.

In one particular embodiment of the disclosed technology, termed “thedemonstration”, 56 successive intervals ranging in duration from 5minutes to 1 day were elected. Refer, for instance, to Table 2. Itshould be understood, however, that any number of intervals of anyduration can be used to implement embodiments of the disclosedtechnology. In Table 2, the term “IST_(n)” refers to the time at whichthe n^(th) interval begins—the interval start time. The durations of thethirteenth, thirty-third, fifty-first, and fifty-fifth interval maychange from one transactive signal to the next; this was done in theillustrated embodiment to make sure that the intervals remain alignedwith major 15-minute, 1-hour, 6-hour, and 1-day transitions.

The shortest interval could be any duration. For instance, the durationmight be limited by the sum of the system's calculation andcommunication latencies. If the system were to use relatively shortintervals (e.g., five minutes or less), it could respond to many dynamicissues, even area control errors, which are typically managed on4-second intervals.

In one embodiment, intervals were defined with increasingly longerdurations into the future because more distant future values may only bemeaningfully and accurately forecasted in a statistical, averaged sense.For example, if one knows the accurate status of a thermostat and thebuilding temperature that the thermostat manages, one may accuratelypredict quite precisely when this system will begin or end its currentheating or cooling cycle. For tomorrow, however, one cannot predictprecisely when each cycle will begin and end, but one can quiteaccurately predict the fraction of time that the system will be activelycooling or heating. (In other embodiments, longer intervals (such asover 1 hour) are avoided. It has been observed, for example, thatintervals longer than 1 hour tend to destroy important boundaries thathave been defined at the boundaries between hours. For example, someutility billing practices presently distinguish “heavy load hours” thatoccur from 6:00 a.m. to 10:00 p.m. Pacific.)

The 56 intervals used in the example embodiment discussed herein extendmore than 3 days into the future, but could extend to any desired timeperiod. The total number of intervals and durations of the longestintervals in the example embodiment were influenced by the desire toallow the system to be unattended for at least three days—the durationof a long holiday weekend.

TABLE 2 Example Intervals Duration No. Intervals Interval Start Times 5minutes 12 IST₀, IST₀ + 0:05, . . . , IST₁₀ + 0:05 15 minutes 20Round(IST₁₁ + 0:15)*, IST₁₂ + 0:15, . . . , IST₃₀ + 0:15 1 hour 18Round(IST₃₁ + 1:00)*, IST₃₂ + 1:00, . . . , IST₄₈ + 1:00 6 hours 4Round(IST₄₉ + 6:00)*, IST₅₀ + 6:00, . . . , IST₅₂ + 6:00 1 day 2Round(IST₅₃ + 1:00:00)*, IST₅₄ + 1:00:00, IST₅₅ + 1:00:00 >3 days 56intervals 57 interval start times (IST) *The function “Round” indicatesrounding down to the next 15-minute, 1-hour, 6-hour, or 1-day intervalstart time. Times are indicated as dd:hh:mm (days, hours, and minutes).

In Table 2, the 57^(th) IST was used to define the end of the 56^(th)interval, which is the final interval in a transactive signal of theexample embodiment.

Published future intervals remain valid and may be used, in principle,until they are overcome by time. This means that a transactive signal'sFriday forecast for a Monday morning interval can be used even if thesystem fails to calculate any new transactive signals through theweekend. In this capability, the system is resilient to temporaryfailures of individual system components. If, however, a part of thesystem fails, the signals that had been predicted much earlier becomeincreasingly dated and inaccurate. The system also loses its ability torecognize and respond to change while new signals are absent. Also,because later intervals have longer duration, signal dynamics diminishas the system relies on progressively longer prior predictions. In oneembodiment, the confidence attribute is degraded (e.g., indicatesdiminished confidence) over time as signals become stale, unupdated.

Although any suitable time standard can be used, embodiments of thedisclosed technology use the Coordinated Universal Time (UTC) standard(ISO/IEC 2004). The UTC can be used, for example, to enforce aconsistent and standardized representation of time across time zones.UTC times are unchanged across time zones and across transitions intoand out of daylight savings periods. In certain embodiments, and inorder to avoid problems with aligning time zones ad contractualobligations that may exist, the use of intervals longer than one hour isavoided.

3.4.2 Confidence Attribute of a Transactive Signal

In some embodiments, transactive signals also include a confidenceattribute that is specified to qualify the values in the transactivesignals. In particular implementations, the confidence attributeestimates the relative positive root-mean-square (RMS) accuracy of eachvalue that is published in a transactive signal. In many cases, thisinterpretation is quite naturally incorporated. For example, forecastsfor renewable energy resources are already qualified in a way comparableto an RMS error.

Some events or conditions are not as naturally represented using themetric relative RMS error. For example, one might have diminishedconfidence if a signal has been delayed or if some component informationto be used in a calculation has become stale. Other examples mightinclude startup conditions while only limited information has beenreceived, suspect status of computational equipment that hosts acalculation, or calculated values that are simply outside a normallyaccepted range for unknown reasons. Nevertheless, these conditions canbe functionally represented by relative RMS error.

The recipient of a value that is accompanied by a high relative RMSerror may use such information in many ways. The local practices andpolicies may differ at each transactive node. The possible responsesinclude, for example, the publication of error or warning flags,performing alternative calculations that are more conservative,resorting to safe default values, using statistical algorithms thatoptimize outcomes or minimize risk, or no action at all.

3.4.3 Transactive Incentive Signal

In particular embodiments, a transactive node has one TIS for any giventime interval and any given calculation result. No differentiation ofTIS value is allowed across a transactive node. If for any reasonelectrical energy should be valued differently across a transactivenode, the transactive node should be divided into more than one node atthe feature that causes different valuation.

In one particular implementation, the TIS is calculated by summing theincurred costs and dividing the sum by the energy to which the costsrefer. The total energy may be thought of as either entire load(including exported energy), or as the entire supply (including importedenergy), at the transactive node. The transactive node can assume thattotal supply is equal to total load. It has been found that it is morenatural to work from the supply side during the formulation of TIS. Itis the costs of the various mixes of supply resources that directlyaffect the TIS.

The input parameters of the TIS formula in Table 3 create a usefulinteroperability boundary. The parameters represent various costs (“C”)and power (“P”), where the subscripts refer to terms for energy (“E”),generation (“G”), capacity (“C”), infrastructure (“I”), or other (“O”).Further, subscript n is the interval number and Δt_(n) is thatinterval's duration. Members of a TCS may be invited to generate theirown functional algorithms that in turn influence the TIS by simplydesigning algorithms that assign values to these various parameters. Theparameters are distinguished by their units. Implementers may select anduse the parameters that most naturally represent the forecasted costimpacts. It should be understood that these parameters are not limitingor even required for a particular component. In certain embodiments ofthe disclosed technology, the functions that generate these parametersare called toolkit resource and incentive functions. Resource functionsmodel energy supply resources. Incentive functions affect the TIS, butthey do not represent any energy resource. Example resource andincentive functions are described in more detail below, includingAppendices B and C.

TABLE 3 Example formula by which the TIS is to be updated${{TIS}_{n} = {\frac{{\sum\limits_{a = 1}^{A}\;{{C_{E,a,n} \cdot {\hat{P}}_{G,a,n} \cdot \Delta}\; t_{n}}} + {\sum\limits_{b = 1}^{B}\;{C_{C,b,n} \cdot {\hat{P}}_{C,b,n}}} + {\sum\limits_{d = 1}^{D}\; C_{O,d,n}}}{\sum\limits_{a = 1}^{A}\;{{{\hat{P}}_{G,a,n} \cdot \Delta}\; t_{n}}} + {\sum\limits_{c = 1}^{C}\; C_{{os},c}}}},$Or${TIS} = {( \frac{{{energy}\mspace{14mu}{cost}} + {{capacity}\mspace{14mu}{cost}} + {{other}\mspace{14mu}{costs}}}{{energy}\mspace{14mu}{resources}} ) + {{offset}\mspace{14mu}{costs}}}$

In other embodiments, infrastructure costs are among the numeratorterms. However, in such embodiments, an undesirable inverse relationshipbetween TIS and total power demand may result. In Table 3,infrastructure costs can be included among the “offset costs”.

3.4.4 Transactive Feedback Signal

The TFS is calculated readily for a radial distribution circuit branch.The transactive node on a radial distribution branch simply sums itspredicted inelastic and elastic loads. The upstream transactive node isthe only resource available to supply the load at this system location,so the TFS is identical to the predicted load for the branch.

The TFS is not as easily predicted between transactive nodes that arenot on a radial distribution branch and have more than one transactiveneighbor. Their network system connections may be meshed. Desirably,power flow is allocated among multiple TFS in a way that would be fullyconsistent with a proper power flow calculation.

In a fully deployed TCS, economic dispatch decisions would be made ateach transactive node to balance load. To the degree that energy can beimported from the transactive node's neighbors, the neighbors' energycompetes with local resources. Any mismatch is desirably allocated amongthe TFSs.

In certain embodiments, each member of a pair of transactive neighborsestimates a TFS for the interface that they share. (The general case ofmeshed networks and bidirectional power flow desirably uses eachtransactive neighbor to publish and receive paired cost (TIS) andquantity (TFS) signals.) The convergence of the two estimates is ametric that can be used to determine whether the two neighbors haveconcluded their negotiated solution or not.

3.5 Transactive Node Object Model

In certain embodiments, the formal model of the transactive node classand its behavior has been specified by the transactive node objectmodel.

3.5.1 Algorithmic Framework

An example model of the algorithmic responsibilities of a transactivenode is introduced below in Appendix B. The details of this model can beused to implement exemplary transactive nodes (e.g., using StandardISO/IEC 18012 (ISO/IEC 2004) or using a unified object-oriented modelinglanguage such as UML-2 (OMG 2013)). The algorithmic framework has provento be applicable across many different types of transactive nodes.

FIG. 12 is a skeleton diagram 1200 of the algorithmic framework at atransactive node. The diagram addresses two main objectives: First, itprovides that the TIS may be calculated. Second, it provides that theTFS may be calculated.

A particular implementation of the function “3. Formulate TIS” isdisclosed in Appendix B. This function receives information aboutintervals, costs of various resources and incentives, and the sum ofimported and generated energy to which the cost information is relevant.

The model states that both the input information and resulting TISvalues are stored in a data buffer. These buffer contents may be minedfor data by those who have permission to do so. But the greaterimportance of the buffered data is that such stored information makesthe system resilient to imperfect communications: the input values froma prior series of forecast intervals remain this transactive node's bestprediction of the input interval values until updated information can bereceived. This is especially useful when the information is delayed orwhen a communication link becomes temporarily severed.

The impacts of energy supply and incentives (or disincentives) at agiven transactive node are received through toolkit resource andincentive functions, a modular library of functions that model the costsand energy supplied by energy resources and other cost incentives ordisincentives at a given transactive node. An example implementation ofthe function “8. Calculate Applicable Toolkit Resources and Incentives”(near the top center of FIG. 12) is disclosed in Appendix B. In certainembodiments, these toolkit functions are not themselves inside thealgorithmic framework, but they inject their influences into theupdating of the TIS via a standardized set of parameters.

A particular implementation of the function “4. Formulate TFS” (at thebottom right of FIG. 12) is disclosed in Appendix B. The objective ofthis algorithmic framework function is to forecast the flow of energybetween it and its transactive neighbors. It therefore receivesinformation about the set of future intervals. It also receivesinformation about forecasted supply and load so that the balance may beallocated to the TFS between this transactive node and its transactiveneighbors.

In certain embodiments, the load forecast has two threads. The firstforecasts the inelastic load. This is the base case that is unaffectedby the TIS. The second thread is the elastic load—the change in loadthat may be attributed to the TIS and events that are generated in lightof the TIS. The separation of these threads is practical and it helpsmeasure and verify system responses. The sum of the inelastic andelastic load forecast components accurately forecasts the actual load.

TABLE 4 Formula for total load used for TFS Total load = Inelasticload + Change in elastic load

The model of a single asset system may forecast both inelastic andelastic load components. For example, the thermostatic building assetmodel forecasts both its normal building load and the changes in loadcaused by temperature setback events. In certain embodiments of thedisclosed technology, a single feeder model forecasted bulk inelasticload that in effect included many inelastic components of responsiveassets. Provided that the components are properly summed for the giventransactive node and not double-counted, it will not matter that thethermostat model did not model its own inelastic load component.

More information about the toolkit resource and incentive and toolkitload functions are discussed below as well as in Appendices B and C.

3.5.2 Signal Timing

In certain embodiments, the transactive node object model includesfunctionality and attributes that control the times at which transactivesignals are transmitted to transactive neighbors. An exemplary timingmodel is discussed in this section, but is not to be construed aslimiting, as any number of intervals having other durations can be used.The example timing model was designed to allow propagation ofinformation about disturbances (e.g., of the electric transmission grid)across the TCS system while reducing unfruitful chatter andcalculations. As noted, the example timing model is not necessarily onethat should be standardized or used in implementations of the systems.

A transactive node should normally not publish transactive signals forwhich any interval starting time has already passed. This expectationcreates a useful framework for the calibration of system clocks. Theerror between clocks at different system locations should desirably besmall compared to the shortest intervals-5 minutes for the exampletiming model. Tight tolerances are, in principle, achievable fortransactive nodes that are internet connected.

In the example timing model, each transactive node, at the beginning ofa 5-minute interval, publishes transactive signals that address theinterval that begins 5 minutes from now and into the future.

Various timers were implemented to avoid unnecessary chatter. One timerbegins when a transactive signal is received. Another timer begins aftera transactive signal is transmitted. No transactive signal of the sametype may be transmitted again until after these timers expire. FIG. 13is a block diagram 1300 illustrating the example timing model.

In one embodiment, the time model is event-based. For example, thetiming model can be adapted to become more responsive to status orcondition events and less reliant upon clock-based events (e.g.,hold-down timers, interval timers). New signals and additionalcalculations can be generated only after significant changes occur toschedules and forecasts, either locally or at remote system locations.As long as forecasts remain accurate, the system should be unperturbed.

Further, sets of prediction intervals that are nested rather thansequential can be used. That is, an understanding that the next 5minutes are a subset of an hour-long interval that is a subset of theday that is a subset of a month, and so on, can be adopted.

Still further, in some instances, a relaxation criterion against whichforecast changes may be compared can be used. The criterion can state aweighting of errors for each interval. For example, if the sum of theerrors exceeds the overall threshold for a transactive signal, then thesignal is updated and republished; otherwise, no signals should betransmitted because the changes are deemed to be insignificant. Thiscriterion can be used in an event-based model wherein imminent andfuture intervals are rapidly iterated (e.g., on an asynchronous basis)until they resolve according to this criterion.

3.6 Transactive Data Collection Layer

In some embodiments, a transactive data collection system layer is alsodefined and used in implementations of the transactive nodes. Forexample, this system layer automatically retrieves toolkit functionoutputs from resource, incentive, and toolkit load functions; gathersresulting TIS and TFS signals that are generated at each node from itstoolkit function inputs; and records various system management eventsand statuses. Because the system is distributed both in time and space,it is desirable to keep track of data provenance, including locations ofnodes from which the data originates, times at which signals aregenerated, and time intervals to which predictive signals refer.

One advantage of a TCS is that the transactive signals, while revealingan aggregated cost and quantity of energy, do not necessarily reveal anysensitive or private data. The model used to store and collectinformation about local resources and loads at a transactive node can beuseful, but such information would normally be shared only with theowner of a set of transactive nodes, who is entitled to receive suchprivileged information. Desirably, little or no sensitive information isshared by neighboring transactive nodes.

“Non-transactive” data can also be defined and collected.Non-transactive data is factual data that is collected from systemmeters and which can be used during analysis to assess the success withwhich the predictive TCS has influenced system loads and its consumptionof various energy resources. Non-transactive data can also includeweather data at each distributed site.

3.7 Influences on the TIS

This section addresses the formulation and interpretation of the TIS.

3.7.1 The TIS is an Aggregate of Multiple Resource and Incentive Costs

In some embodiments, while each TIS states a value for each futureinterval, each said value may be composed of a plurality of variousresource and incentive cost components. This concept is demonstrated bydiagram 1400 in FIG. 14, which shows multiple stacked component costs,the sum of which is the published TIS value. The biggest cost component,in this example, is the unit cost of the energy that is received by thistransactive node from its transactive neighbors (the transactivecomponent). The remaining components are ranked as the cost ofinfrastructure and the unit costs of wind, hydroelectric, andfossil-fueled resources.

Observe that influences are inherited from neighboring transactive nodesthat supply this transactive node. For example, if 8% of a TIS value isfrom the costs of fossil energy resources, and if this transactive nodeis supplied another 10% of its resources by a neighbor for which 10% ofthis neighbor's TIS value is from fossil resources, then the totalimpact of fossil energy on the TIS at this transactive node would be8%+10%×10%=9%. Therefore, one can look to propagated resource mixes one,two, or even more neighbors distant to accurately assess the resourcesupply mix at this transactive node.

3.7.2 TIS Calibration Measurements Identified

As discussed, in certain embodiments, delivered cost of energy is usedas the metric for TIS magnitude. This metric is useful because (1) itprovides a straight path to using the signal for revenue, if otherimplementations choose to do so, and (2) comparable calibrationstandards exist at some locations within a TCS for this metric.

In a distributed system, checks and balances are desirable to make surethat the TIS, which is collaboratively formulated, is meaningful andfair. The first step toward accomplishing this was to establish a commonsemantic understanding of the TIS as, for one embodiment, the deliveredcost of energy at a location. The second step is the comparison of theTIS and its components against comparable calibration standards. Forexample, existing and historical contracts define the average unit costof energy among many suppliers and recipients of electrical energy.Distribution utilities can accurately state how much they paid for aunit of energy during the past year. Therefore, the TIS and any othervalid representation of the delivered cost of energy at a systemlocation should be comparable over long periods of time.

3.7.3 Resource Toolkit Functions

Adequate energy resources are desirably received into or dispatched at atransactive node to balance system load. The mix of dispatched energyresources can be determined in a distributed manner (though it is alsopossible to use a central determination for smaller scaleimplementations).

In certain embodiments, resource toolkit functions from a library offunctions are the functions that calculate the quantity of energy andits cost impacts toward the formulation of the TIS at a transactivenode. The resource toolkit functions can reside at any of thetransactive nodes (e.g., transmission zone nodes, which each representlarge regions of a region's generation and transmission systems). One ormore of the following functions can be used to represent groups of (orindividual) energy resources:

-   -   Non-transactive energy function—represents energy imported into        the system from entities that are not transactive nodes.    -   Transactive energy function—represents energy imported from a        neighboring transactive node.    -   Wind energy function—represents energy from wind farms in this        transactive node.    -   Hydropower generation energy function—represents energy from        hydropower at this transactive node.    -   Fossil generation energy function—represents energy from fossil        (more generally, “thermal”) resources at this transactive node.    -   Solar energy resource function—represents energy from solar        resources at this transactive node.

3.7.4 Incentive Toolkit Functions

Incentive functions are similar to resource functions, but they are nottied to energy supply. One or more of the following exemplary incentivefunctions can be used in implementations of the disclosed technology:

-   -   Transmission congestion management function—if the power flowing        through electricity transmission lines between two transactive        nodes ever approaches the capacity limit on the transmission        lines, this function adds cost disincentives to the downstream        transactive node to reduce load on the line.    -   Cost of general infrastructure function—a cost that is amortized        over time to represent the cost impacts of built infrastructure        that has not otherwise been captured in the system. The offset        from this function calibrates the TIS over time, pulling it        gradually toward a reasonable TIS at each transactive node.    -   Demand charges function—this is an incentive toolkit function        that can be applied at utility-site transactive nodes. Wholesale        electricity suppliers charge their utility customers according        to quite complex cost structures. This function attempts to        represent the cost impacts of demand charges and, to a lesser        degree, time-of-use charges. Functions have been drafted to        represent the cost structures of, for example, regional power        administrations.

3.8 Influences on the TFS

A TFS represents the power flowing between a transactive node and itstransactive neighbor during the imminent and future intervals. Themajority of the power flow is usually inelastic: it is unaffected by thepredicted unit cost of the energy—the TIS. If the transactive node hostsresponsive asset systems, these systems might observe the TIS and changetheir forecast of how much energy they will consume during a futureinterval—they are elastic. The transactive node state model keeps trackof the changes in load that are anticipated from these elastic assetsystems.

Responsive asset systems that curtail load reduce load at a transactivenode and therefore tend to reduce the energy that is generated at orimported into the transactive node.

Demand-side generators have the same impact when they generate energyand displace load at the transactive node.

Even more useful are responsive asset systems that can increase theirenergy consumption (or equivalently, reduce their demand-sidegeneration). These asset systems thereby increase system load at theirtransactive nodes and increase the energy that is either generated at orimported into the transactive node. This response is increasingly usefulin power grids that experience excessive generation, as now occurs inregions that have high wind-power penetration.

3.8.1 TFS Calibration Measurements Identified

A straightforward comparison standard exists for TFS values at manysystem locations. Because the TFS represents forecasted power flow, theaccuracy of the forecasted power-flow values in a TFS may be comparedagainst actual metered power at that point in the power grid. Forexample, the electricity supplied to a distribution by its electricitysupplier is accurately metered.

3.8.2 Inelastic Load Prediction Functions

Inelastic load functions forecast baseline load that is unaffected bythe TIS. Inelastic load functions can be defined for each residential,commercial, and industrial load type. The load from these models can bescaled by the numbers of each customer type. Alternatively, a parametricmodel can be used that can be trained by historical data. The modelappears to perform similarly for all of the different load types. Theforecast model creates a correlation to forecasted weatherinformation—including at least ambient temperature. If available, themodel can also incorporate recent measurement data to improve theforecast.

3.8.3 Elastic Load Functions

Elastic toolkit load functions in conjunction with asset models modelhow responsive asset systems are influenced by the TIS. In certainembodiments, these functions have two principal responsibilities: First,the toolkit load function predicts when events may occur and how longthey will last. Second, an asset model forecasts the change in load thatwill occur during an event for the given asset system.

Elastic toolkit load functions can be categorized as follows based onthe nature of their forecasted events:

-   -   Event-driven—several events may be called each month. The        principal challenge is to allocate a limited number of allowed        yearly, monthly, and daily events (e.g., curtailment events)        based on the forecasted TIS. Additional restrictions may apply        to the minimum and maximum durations of the events for a given        asset system.    -   Daily events (sometimes referred to herein as “time-of-use”        events)—events are expected to occur almost daily. The events        might be specified differently for weekdays, weekend days, and        holidays. The principal challenge is to place an event at the        best time of day based on the TIS. Additional restrictions may        apply to the minimum and maximum durations of the events for        each day type.    -   Continuous—in some embodiments, dynamic responses are being made        every interval. The challenge is not so much to specify events        as to state a functional relationship between each TIS value and        a system response.

An asset model then models the change in load during the above eventtypes. It has been found that many possible pairings exist between eventtypes and asset model types. For example, a water heater asset model maybe used with either event-driven or daily event types. In principle,water heaters could be manufactured to have continuous responses.

By way of example, one or more of the following exemplary asset modelscan be applied in an implementation of the disclosed technology:

-   -   water heater population—for instance, the population of        residential 40-gallon water heaters controlled by in-line        switches (e.g., demand-response units). (Models for other sizes        of water heater can also be used.) After the timing of events        has been predicted, the challenge is to predict the power and        energy that will be curtailed by the systems response.    -   thermostatic space conditioning with temperature setback—in one        implementation, a first-order thermal model of a building is        simulated. The model is scaled by numbers of building types and        their thermal properties, parameters which are desirably        configured by the implementer of this elastic toolkit load        function. Dynamic inputs include ambient temperature, solar        insolation, and modeled target interior temperatures that        represent occupancy temperature settings. During events, the        modeled target temperature is raised or lowered, depending on        whether it is cooling or heating season. An advantage of using        this thermal model is that it predicts thermal rebound if        buildings that have had their thermostat load set back return to        normal operation.    -   thermostatic space conditioning with cycling of the heating,        ventilating and air-conditioning (HVAC) unit—uses the same        first-order thermal model and simulation as for temperature        setback, but events cause a reduction in modeled power of the        space conditioning equipment to represent the cycling of HVAC        equipment.    -   stationary battery storage systems—the TIS is an input to a        simulation model that attempts to maximize the cost of energy        discharged into the grid and minimize the cost of energy used to        charge the batteries. The exchange of energy is scaled by and        limited by the modeled useable energy capacity of the batteries        and by the capacity of the bidirectional power converter that        charges and discharges power into and out from the batteries.        The responsiveness of the system may also be modified depending        on how frequently the system's owner will permit it to become        alternately charged and discharged.    -   controlled distribution voltage systems—estimate the change in        load that will accompany a change in distribution voltage during        an event. In one simplified implementation, the asset model uses        a static factor to represent the change in load as a function of        change in a feeder's voltage.    -   distributed generators—models a change in generation during        events. In most cases, the generator becomes activated during        events, and the generator supplies its nameplate rated power or        another prescribed power level during the event.    -   in-home display and portal notifications—in one implementation,        event periods are presumed to be indicated to in-home displays        or portals as a small number of discrete states (e.g., a        high-price event). The change in load is, of course, dependent        upon the election of a population of energy customers to        voluntarily turn their devices on or off. A typical change in        power is forecasted by time of day that may be scaled by the        numbers of in-home displays or portals in the population.    -   a suite of smart appliances, including washer, dryer, and        dishwasher—These appliances are similar to in-home displays in        that they notify customers of events during which the smart        appliance owners may elect to defer electrical load. In another        exemplary implementation, these appliances have additional        features by which customers may better automate decisions to        delay the appliance loads, and some energy reduction is also        achieved automatically when the appliances are in their        conservation mode. The change in load is modeled simply as a        fraction of typical appliance load by time of day and by        appliance type.

Table 5 summarizes the potential pairings of the listed exemplary assetmodels with appropriate event types. Examples for some of these pairingsare described in the appendices below. Implementations for otherpairings can be developed by those skilled in the art in view of thisdisclosure.

TABLE 5 Pairing of Response Characteristics with Asset Models Assetmodels Event-Driven Daily Events Real-Time Water heaters Y Y YThermostat setback Y Y Y HVAC cycling Y Y Y Battery storage Y Y YDistribution voltage control Y Y Y Distributed generators Y Y Y In-homedisplays/portals Y Y Y Other smart appliances Y Y Y

3.9 Additional Observations

In a fully deployed TCS, regional transmission and generation ownersformulate TIS signals by stating the temporal and locational value ofresources at many transmission and generation sites in the region, andthe TFS, a feedback signal, influences their resource dispatch decisionsat these distributed locations.

Further, as household devices become more intelligent, there willeventually exist vast populations of flexible, responsive assets thatwould be active in a TCS. These assets will be available to modify theirconsumption at each update interval. A TCS invites the demand side toparticipate in the system objectives on equal footing with supply.

3.10 Interoperability

Implementations of the disclosed technology can be standardized, ifdesired. Standardization efforts may be at a variety of differentlevels. For instance, the TCS can be defined at the organization andinformational level. In this regard, FIG. 15 is a diagram 1500 showingan example skeleton model of a standard transactive node and the signalsthat it communicates with other transactive nodes and with modules andsystems, some of which can be outside the boundary of a standardizedsystem. Typically, neighboring transactive nodes will have to agreebetween themselves concerning an Interoperability Framework, includingthe remaining interoperability levels (“Technical/Syntactical” levels).Between unrelated sites, this negotiation is unique. However, ifneighbor nodes share the same owner, a common technology may be appliedto all the owner's transactive nodes. The TCS standard should desirablybe agnostic of the technologies by which it may be implemented.

Certain implementers can choose to define additional implementationdetails beyond those in the standard. The implementations might, forexample, further specify the syntactical levels of interoperability.These implementations should abide by and make reference to the mainstandard. However, the new implementations may themselves becomestandards, or they may be recognized as reference implementations ofTCS.

Further, implementers may desire to keep their particular code (e.g.,code for a toolkit function) confidential. Such a scenario is feasibleso long as the resulting signals are conformant.

Embodiments of the disclosed technology can be integrated with academicdistributed control approaches. For instance, the specification oftransactive signals can be harmonized with signal characteristicsspecified in simulation studies. An outcome of such harmonization willbe that the transactive signal that represents power flow will be acomplex representation. (This use of complex here is mathematical. Acomplex number has real and imaginary components. The real componentrepresents real power; the imaginary component represents the flow ofreactive electrical power.)

Embodiments of the disclosed technology can be harmonized with LMPapproaches. For instance, the practices of LMP and TCS can beharmonized, potentially allowing the TCS approach to compete with,supplement, or gain equal footing with LMP practices.

Embodiments of the disclosed technology can also be harmonized withother TCS approaches. For example, the price-like signal used inembodiments of the TCS approach may be modeled after cost, price, orcompetitive bids.

4 Overall Design for Embodiments of the Disclosed Transactive Controland Coordination System

In this section, additional details concerning the overall design forembodiments of a transactive control and coordination system accordingto the disclosed technology will be introduced. The discussion belowalso provides a supplemental discussion of the transactive controlsignals themselves. This discussion may, in some instances, berepetitive to the discussion above but is included herein for the sakeof completeness.

4.1 Architecture of an Installed System Design

The architecture of an installed system is more diverse than for typicalcomputer network designs. For instance, an installed system comprisesgeneration, responsive assets, the electricity transmission anddistribution systems, and digital communication and intelligence. Thesystem therefore should consider:

-   -   Physical, geographical location    -   Electrical connectivity    -   Information flow.

These components are interdependent, and a close correlation willtypically exist and be maintained between them.

4.1.1 Physical, Geographical Architecture

The physical, geographical system architecture captures the physicallocations of each piece of the installed system. Physical location canbe influential to transactive control because local attributes (e.g.,weather) affect the behaviors of equipment, end users, and responsiveassets. One tenet of transactive control is that the value of suppliedelectrical energy is location-dependent. Physical, geographicalarchitecture is easily captured on a conventional map.

4.1.2 Electrical Connectivity Architecture—the Nodal Hierarchy

The electrical connectivity system architecture captures the flow ofelectrical energy through the installed system. One tenet of transactivecontrol is that the communication of value and operational opportunities(e.g., the transactive signals) in a transactive control andcoordination system should logically follow the pathways of electricalenergy flow. Existing and future power capacity constraints are highlypath-dependent.

In certain embodiments, the electrical connectivity within an installedtransactive control and coordination system forms a hierarchy of nodes.Here, the word hierarchy refers to a flow direction of electrical powerand is not necessarily a static assignment. Electrical transmissionsystems are typically mesh (not radial) systems, meaning that parallelpaths in the transmission system compete to supply load. The directionof electrical power in the transmission system may change. Some of thiscomplexity will not be discussed in detail herein because embodiments ofthe disclosed technology can be adapted for such complexities usingsoftware tools that properly model meshed transmission power flow.

4.1.3 Information Flow in the Transactive Control and CoordinationSystem

The information flow design captures the flow of data and informationwithin an installed system. An information flow architecture alsoindicates where manual and automated decisions are made. The informationflow architecture can include, for example,

-   -   The communication channels used to transport transactive control        signals    -   The communication channels used to transport asset control        signals    -   The communication channels used for other data that supports        local, regional, and client-run experiments    -   Meter data channels through which meter data flows    -   Locations within the information flow where functional        calculations, like the estimation of future electrical load,        take place    -   Any other communication channels necessary to employ the        installed transactive control and coordination system.

The information flow architecture can also capture details about thecommunication channels and signals, including communication media,protocols, bandwidth, formats, software tools, exemplary functionalcomputations, and security attributes and practices.

4.2 A Generalized Transactive Control and Coordination System

This section introduces embodiments of hierarchical transactive controlthat can be used in an installed system. Prior to recent efforts tobuild a smarter grid, most all opportunities to manage and controlelectrical power have been managed quite centrally from the supplyside—bulk electrical generation and transmission. The role of the powergrid has been simply to satisfy electrical demand—the energy consumptionpatterns of all the end users. Embodiments of the smart grid accordingto the disclosed technology will engage end users and responsive assetsthroughout the grid, resulting in a cooperative, more distributedapproach. Transactive control can facilitate this migration to a smartergrid.

4.3 Review of Transactive Control

Transactive control is a bidirectionally negotiated system behavior.Market-like principles facilitate the negotiation; however, the signalsneed not be used to account for any monetary or revenue exchanges. Intheory, the “winning” behaviors are optimal in some sense, havingcompeted successfully in a “market” against alternative actions thatcould have been taken.

One or more of the following are characteristics that can be exhibitedin embodiments of a transactive control and coordination systemaccording to the disclosed technology:

-   -   Bidirectional communication—transactive control differs from the        similar practice of real-time nodal pricing in that it uses        dynamic feedback from its end uses.    -   Incentives and feedback are communicated via one nodal signal—at        a node, a single incentive time series is transported        downstream, and a single feedback time series is transported        upstream. Components of the incentive and feedback signals are        additively combined into one incentive and one feedback time        series. Using a single signal facilitates interoperability        between multiple operational objectives and multiple responsive        asset systems.    -   Multiple operational objectives and responsive assets are        simultaneously engaged—unlike present programmatic approaches        that create unique engineered couplings between one operational        objective and one or more responsive assets. Because operational        objectives can be integrated into a single incentive time        series, transactive control enables each responsive asset to        respond to the integrated set of operational objectives. As a        corollary, each operational objective may be acted upon by many        responsive assets.    -   The signal in a transactive control and coordination system can        be dynamic on multiple time scales—transactive control signals        are dynamic. In principle, the time intervals may be made        infinitesimally small. A transactive control and coordination        system could respond to a need for fast grid regulation, for        example, if its time intervals were made short compared to the        dynamic performance of fast regulation services. Regardless, the        responsive assets may respond according to each asset's own        dynamic capabilities and limitations. Not all parts of the        system need to agree on and use the same interval if dissimilar        interval signals can be added or interpolated to create valid        comparisons between signals that have dissimilar intervals.    -   Interoperability is facilitated—transactive control facilitates        interoperability at the organizational and informational levels,        and it allows technical layers of interoperability to become        satisfied by any, or many, appropriate standards. This attribute        helps make transactive control a worthy candidate for        interoperable, regional smart grid communications.    -   Responds 24/7—transactive control can be always active. Small        improvements and responses can be made throughout a day, not        only during the worst several hours of the year.    -   End-user friendly—by taking advantage of numerous short        intervals and distributed digital intelligence, impacts on end        users can be reduced, if not entirely eliminated. For instance,        end users should have a final say concerning their comfort and        should be provided options to temporarily opt out of responses.    -   Facilitates distributed control—transactive control facilitates        distributed intelligence and control. Centralized control is        reduced or eliminated.    -   Uses low bandwidth—the elimination of unique signals and the        distribution of control should reduce communication bandwidth.

The transactive control technique of this disclosure can be compared toother approaches to transactive control, specifically the GridWise®Olympic Peninsula Project. Table 6 summarizes the major differencesbetween the transactive control approach used during the OlympicPeninsula Project and embodiments of the disclosed transactive controlapproach.

TABLE 6 Comparison between the GridWise Olympic Peninsula Project andEmbodiments of the Disclosed Technology GridWise Olympic PeninsulaEmbodiments of the Disclosed Project Technology Electricity Combinationsof fixed and Various approaches, as will be customer various dynamicprice accounts. determined individually by incentives The projectmaintained a shadow participating utilities. Incentive market andcustomer accounts practices should be sustainable. that were separatefrom utility billing. Feedback A bid was received from every Eachtransactive node reports signal responsive asset every five feedbackthat consists of a time series minutes ($/MWhr). of expected energyconsumption during each time interval into the future (kWhr/interval).Operational One single transmission line Multiple constraints, regionalobjectives constraint was addressed. renewable energy availability,addressed economic dispatch of resources, hydrogeneration, peak loadmitigation, balancing resources, spot-market purchase mitigation, . . .Future time Not more than five minutes. To be determined (probably fromone horizon to two days). Approach for Explicit clearing of the two-wayUses iterative resolution of the resolution of “market” conducted everyfive “market” future intervals over time. the “market” minutes. Shortesttime Five minutes for real-time price To be determined (perhaps fiveintervals customers. minutes). supported Architecture Centralized.Information flow Enforces a nodal hierarchy, including was managed froma central plans for standardization and operations center and includedextensibility of the hierarchy. the aggregator's communication Launchedat multiple initial transactive servers. node sites.

Exemplary components of embodiments of the transactive control andcoordination system include one or more of:

-   -   Transactive nodes—a physical point within an electrical        connectivity map of the system. Electrical energy flows through        a transactive node. A transactive node is not to be confused        with locations within the information flow map that might also        be called “nodes.”    -   Transactive signals—each node location receives an incentive        signal from upstream and generates a corresponding feedback        signal to be sent back upstream. These two signals—the        transactive incentive signal and its feedback—together are the        transactive signals.    -   Responsive assets—the “prime movers” of the transactive control        and coordination system that can modify consumption of        electrical energy (e.g., in response to the current values of        the transactive signals).    -   Enabling assets—assets like communication infrastructure and        metering that cannot by themselves modify energy consumption.        Cost-benefit analysis typically cannot be properly assessed for        an enabling asset alone because it represents only costs but no        measureable smart grid benefits. The expenses of enabling assets        are desirably allocated among and borne by truly responsive        assets.

Responsive and enabling assets are more thoroughly discussed below.

4.4 Transactive Signals

This section describes example transactive signals and their use by thedemonstration.

4.4.1 Introduction to Transactive Signals

In certain embodiments of the disclosed technology, there are twotransactive signals at each transactive node:

-   -   A transactive incentive signal (TIS) time series comprising the        aggregated present and future values of the electricity supplied        to and through each transactive node; and    -   The transactive load feedback signal (TFS) comprising the sum of        an estimate of the future quantity unresponsive and responsive        electrical load to be consumed by the entire load downstream        from the transactive node.

Each of the two signals is a time series, meaning that each is a vectorof numbers, one for the present time interval and others for each futuretime interval (e.g., at least a day into the future). The time intervaland horizon into the future can vary from embodiment to embodiment. Insome embodiments, the time interval is five minutes. Shorter intervalsthan this would permit the demonstration system to provide additionalancillary services. Further, in some embodiments, shorter intervals areused for the near term and longer intervals into the signals' future.The signals' time horizon desirably extends at least to the future timewhen resource dispatch decisions are being made for the region.

The transactive signals at time t₀ can have the forms:TIS={TIS(t ₀),TIS(t ₀ +Δt),TIS(t ₀+2Δt),TIS(t ₀+3Δt), . . . ,TIS(t _(f)−Δt)}TFS={TFS(t ₀),TFS(t ₀ +Δt),TFS(t ₀+2Δt),TFS(t ₀+3Δt), . . . ,TFS(t _(f)−Δt)},where TIS and TFS are the transactive incentive and feedback signals,respectively, Δt is the selected time interval, and t_(f) is the end ofthe prediction time horizon. The given time signal series can be updatednext at time t₀+Δt.

The time-series elements of these two transactive signals are paired foreach future time interval. This pairing between transactive incentivesignal and transactive feedback signal is illustrated in block diagram1600 of FIG. 16, which also portrays how an upward trend in thetransactive incentive signal for any future time interval should resultin a corresponding downward trend in load supplied through thetransactive node for that time interval. If the transactive nodesupplies any responsive electrical load (e.g., responsive assets thatare responsive to the transactive incentive signal), the responsiveelectrical load should respond to changes in the transactive incentivesignal. FIG. 16 indicates further that the granularity of the intervalsfor these signals could be relatively fine in the near term and courserinto the distant future.

During the application of transactive signals, sensibility checks anddefault behaviors are desirably planned. For example, the nodes can beprovided some independence to recognize and discount nonsensical signalsthat are believed to be erroneous. When no signals are received bytransactive nodes, as may be the case when there has been a problem orequipment failure somewhere in the system, the nodes should again havethe independence to revert to safe, bounded behaviors.

4.4.2 Transactive Incentive Signal

In particular embodiments of the disclosed technology, the transactiveincentive time series is the main transactive signal. Each transactivenode will typically have a unique blend of energy suppliers, upstreamtransmission pathways and distances, operational practices, localinfrastructure, and/or downstream customers. Therefore, the values ofthe transactive incentive signal can be unique at a transactive node inthe system.

In certain implementations, the basis for the transactive signal seriesat any node is a weighted sum of the transactive incentive signalsreceived by that transactive node from immediately upstream transactivenodes that supply it electrical energy. The default approach, forexample, can be to weigh the transactive signals according to therelative fraction of the node's power that is supplied from eachupstream source as described below.

Each transactive node can also modify the transactive incentive signalthat it relays downstream. At each transactive node, local conditionsare analyzed and the incentive signal modified (or left unchanged) basedon the local conditions. Modification of the incentive signal is for thepurpose of influencing the behavior of responsive assets downstream fromthe node. The basic action at any node can be simply represented as:TIS_(output)(t)=Weighted average(TIS_(input)(t))+New incentives(t)TIS_(output)(t)=Weighted average(TIS_(input)(t))+New incentives(t).

Examples of how and why a transactive node will modify its transactiveincentive signal include:

-   -   The expense of energy supplied at the node—those transactive        nodes that host generation have the opportunity and        responsibility to insert the initial incentive signal values for        that resource. For example, the incentive signal may reflect        fuel expenses, infrastructure expenses, and/or all other        expenses that are incurred to operate the resource. Ideally, the        sum of incentives inserted for a generator over a year or longer        should approach the sum of its true operational expenses.    -   Infrastructure constraints or congestion avoidance imposed by        the node—if the node itself becomes electrically constrained, it        should modify the transactive incentive signal to incentivize        downstream behavior that will alleviate the constraint. For        example, the modification might be set equivalent to the        incremental expense that would be incurred from the consequent        shortening of a piece of equipment's lifetime, plus the        likelihood that expenses will be incurred from outages after        exceeding equipment ratings.    -   Amortization and other expenses of installed equipment—even idle        equipment can be argued to incur expenses. One should insert an        expense for maintaining necessary infrastructure of the node.        This incentive component, for example, is part of a natural        disincentive for consuming energy far from where it is generated        and thus using transmission infrastructure.    -   Energy losses—modifications of the transactive incentive signal        may account for line, transformation, and equipment energy        losses.    -   Operational objectives that occur at business entity        boundaries—especially at business entity boundaries, the system        shall encounter new operational objectives and values that        should be respected. For example, certain utilities manage spot        market purchases that are not influential in the regional        hierarchy but become important at the boundaries of that        utility.

The formulation of the transactive incentive signal can, but need notdirectly, incorporate actual allocations and financial metrics used byutilities and other business entities; the transactive incentive signalcan instead be formulated to allocate expenses in a way that will induceuseful responses for the entity that owns a transactive node. However, afaithful transactive incentive signal formulation should approach thesame overall value as for actual expense reporting over long periods oftime. There is nothing that would prevent the transactive control andcoordination system from supporting markets and revenue accounting inother formulations.

The incentive signal can have a variety of forms or units, but in someembodiments uses units of $/MWhr (or other equivalent, such as a numberor value that is proportional (linearly or otherwise) to this unit).Thus, the signal need not be an actual price, but can be representativeof a price or economic unit. One tenet of embodiments of the disclosedtransactive control scheme is that items that are valued at a locationin the system should be combined into one shared signal, and that can beachieved only after there is consensus about a common metric unit to beused by the signal. This principle will help enforce that businessentities' operational objectives should fairly compete.

4.4.3 Transactive Load Feedback Signal

Corresponding to a transactive incentive signal time interval is atransactive load feedback signal (e.g., in the kW or other equivalent orrepresentative unit). This transactive feedback signal time seriesincludes the present and future electrical load that is predicted to besupplied through the transactive node during each time interval. In someembodiments, the signal is the sum of the unresponsive electric loadthat is not affected by the transactive signal and the responsiveelectric load that can monitor and respond to the transactive incentivesignal.TFS_(output)(t)=ΣTFS_(unresponsive,input)(t)+ΣTFS_(responsive,input)(t,TIS_(output)(t))

The transactive feedback signal is not a “load forecast” of the typethat some utilities prepare as they plan resource commitments. There areno direct penalties to be incurred by subprojects when their transactivefeedback signals prove inaccurate. The transactive control approachmight diminish the importance of load forecasts in the future if theflexibility provided by transactive control can be shown to displacesome of the need for predictive accuracy. Interestingly, the accuracy ofa node's transactive feedback signal prediction may always be testedagainst the true consumption that is measured eventually at thetransactive node. In some embodiments, the intelligence at a transactivenode can “learn” over time to improve its own predictions. Neighboringtransactive nodes learn also from an adjacent transactive node'sinaccuracies and may choose to alter or suspect that transactive node'soutputs.

In some embodiments, the inputs to the transactive feedback signal at atransactive node include any one or more of the following types ofinputs:

-   -   Transactive feedback signals generated from transactive nodes        that are immediately downstream;    -   Transactive feedback signals generated from smart responsive        assets that are controlled from the present transactive node's        position in the hierarchy;    -   Raw unresponsive load measurements that may be subjected to        further computation or modeling to predict the remaining future        time intervals; and/or    -   Raw responsive load measurements from responsive assets that do        not themselves predict and provide transactive feedback signals        but instead rely on the transactive node to perform predictions.

4.4.4 Implications for Customer and Utility Incentives

As has been stated, the transactive incentive signal is not intended toaccount for monetary exchanges or revenue between regional entities.However, the transactive incentive signal could become the foundationfor regional exchanges or revenues. The transactive incentive signal mayalso be used as a basis for customer incentives if the subprojects canestablish workable shadow accounts for these customers.

4.5 Transactive Nodes

Any of the physical locations in the electrical connectivityarchitecture of a power system can be transactive nodes. A node is alocation or piece of equipment that electrical power flows through. Theterm “hierarchy” is used to describe a set of transactive nodes that mayextend all the way upstream to bulk generators and all the waydownstream to electrical loads.

4.5.1 Responsibilities of a Transactive Node

In certain embodiments, a location or piece of equipment in theelectrical connectivity architecture is described as a transactive nodeif it performs one or both of the following:

-   -   Accepts at least one transactive incentive signal time series        from upstream and sends a transactive incentive signal time        series downstream. If multiple transactive incentive signals are        received from upstream, a transactive node blends these        incentives into a single transactive incentive signal to be sent        downstream.    -   Accepts at least one transactive feedback time series from        downstream and sends at least one transactive feedback time        series upstream. A transactive node can further predict        electrical load and can thereby convert raw electrical load        meter readings, as necessary, into transactive feedback time        series.

A transactive node can also: modify the output transactive incentivesignal to address any local operational objective that exists at thetransactive node; and/or predict the responsive electric load from anyresponsive assets that are being controlled from the location of thetransactive node.

These responsibilities of a transactive node are summarized by blockdiagram 1700 of FIG. 17, where the “prediction and control machine” isthe intelligence (typically implemented as software executed bycomputing hardware associated with a transactive node) that modifies theoutput transactive incentive signal, predicts the behaviors ofdownstream electrical load, and controls responsive assets at thetransactive node.

Any one or more of the following functional behaviors can be carried outby transactive nodes:

-   -   Basic transactive node functions    -   Management of electrical constraints    -   Management of electrical supply    -   Management of responsive assets.

These general functional behaviors help form the basis for a basicbuilding-block model of a transactive node, whose models may be linkedtogether to model the behaviors of the transactive nodes in a completednodal hierarchy. Each of these functional behaviors is discussed in moredetail below.

4.5.2 Basic Transactive Node

This section addresses the most basic functions that a point in theelectrical connectivity architecture (hierarchy) performs as part of itsrole as a transactive node. First, a transactive node desirably is ableto receive at least one transactive signal and “blend” the signals intoa single transactive signal output to be sent downstream through thehierarchy. For purposes of this discussion, this basic function istermed the incentive blending function and is illustrated in blockdiagram 1800 in FIG. 18. Secondly, a transactive node desirably is ableto receive or meter the downstream electric load that it supplies andaggregate this information and these measurements into a completetransactive feedback signal to be sent upstream through the hierarchy.For purposes of this discussion, this basic function is termed loadaggregation, and is also illustrated in FIG. 18.

As a starting point for the design, the default incentive blendingfunction can be assigned as a weighted average of the transactiveincentive signals that are received at the transactive node fromupstream, where the weighting is performed according to the energyreceived from each source during the interval. For instance, thisweighted average can be formulated as:

${{TSF}_{output}(t)} = {\frac{{{{TSF}_{{input}\mspace{11mu} 1}(t)} \cdot {{TIS}_{{input}\mspace{11mu} 1}(t)}} + {{{TFS}_{{input}\mspace{11mu} 2}(t)} \cdot {{TIS}_{{input}\mspace{11mu} 2}(t)}} + \ldots}{{{TSF}_{{input}\mspace{11mu} 1}(t)} + {{TFS}_{{input}\mspace{11mu} 2}(t)} + \ldots}.}$

It is noteworthy that the relative electrical energy to be received frommultiple source inputs to a transactive node during a time intervalcannot be directly controlled by the transactive node and may only bepredicted imperfectly from the transactive node's limited view of thesystem. This might not be problematic (or even evident) for transactivenodes that exist within largely radial distribution systems, but maybecome more evident for transactive nodes within highly redundanttransmission pathways and near dispatchable generators. This observationresults from the more distributed nature of the disclosed transactivecontrol and coordination system and can be contrasted with systems wheretransmission system conditions are predicted by load flow calculationmethods that assume nearly complete system visibility and usesimultaneous solution of the entire system's status.

The load aggregation function is conceptually simple, but complexitiespotentially arise from the breadth of downstream electrical load typesand conditions. In principle, the purpose of the load aggregationfunction is simply to receive or measure electrical load that issupplied through the transactive node and to convert these measurementsand this information into the transactive feedback signal, including aprediction of the entire electrical load to be supplied through thetransactive node for each time interval. The transactive node canimplement this functionality according to one or more of the followingcases:

Case 1.

If there are transactive nodes immediately downstream from the giventransactive node, then the transactive feedback signals that arereceived from them is already in the right format and should simply beadded.

Case 2.

The electric load that is not from responsive assets and is not suppliedby another downstream node is predicted and converted into the format ofthe transactive feedback signal. This prediction might rely on an activemodel of the behaviors of the supplied load or its components. Theseunresponsive asset behaviors might be influenced by weather, day ofweek, customer habits, and/or many other conditions, but they are notaffected by the transactive incentive signal.

Case 3.

A third case is similar to case 2 above but further includesresponsiveness to the transactive node's transactive incentive outputsignal.

4.5.3 Constraint Transactive Node

A transactive node that manages an electrically constrained piece ofequipment at the transactive node additionally may modify its outputtransactive incentive signal to manage this constraint. This additionalfunction is shown in diagram 1900 of FIG. 19 in line with the downstreamoutput of the transactive node's transactive incentive signal. Thisfunction draws upon predicted electrical load and other localinformation, including the knowledge of the electrical constraintmagnitude.

In summary, the transactive incentive signal can be made responsive tothe constraint, and the downstream responsive assets can be made toreduce or curtail their consumption when the transactive incentivesignal becomes high.

In contrast to a transactive approach where price is determined by atwo-way clearing of a market, embodiments of the disclosed technologybase the magnitude of the transactive incentive signal on actual risksand expenses. The transactive incentive signal is therefore not amarginal price but is instead a transparent accumulation of incurredexpenses. This approach responds to the criticism received by marginalpricing that it results in more, not less, expense to customers.

If a constraint is to be addressed, the transactive node can beassociated with the constrained piece of equipment. This practice canhelp in situations where it is desirable to have only one outputtransactive incentive signal be necessary from the perspective of thetransactive node.

In some instances, local situation information can also be received fromthis function, which may generate useful alerts, for example, for systemoperators. That is, the prediction of constrained operation at atransactive node is reflected in both the transactive incentive andfeedback signals at that node, and useful notifications may be generatedif thresholds are exceeded in these signals.

4.5.4 Load Transactive Node

This transactive node function addresses a node associated with a loadasset and builds on the structure of a basic node. In diagram 2000 ofFIG. 20, a function is shown to reside on the path of the outputtransactive feedback signal. This function allows local situationalinformation to affect prediction of future electric load, but it alsoincludes the effect of the transactive incentive signal towardpredicting energy consumption by responsive load. The responsive load isthe load consumption of those responsive assets that are controlled atthe transactive node. (Responsive assets that are controlled atdownstream nodes are also responsive, but their behaviors are alreadycaptured in the basic transactive node's summing of signals fromdownstream transactive nodes.)

Smaller distributed generation can be addressed by using the loadtransactive node functions. Distributed generators can make theirdecisions to run or not based on the transactive incentive signal whichis provided by the load transactive node functions. When the smallgenerator operates, it effectively reduces downstream electrical load.

The transactive node further uses its version of the transactiveincentive signal to functionally control its responsive assets via atoolkit load function selected from a library of such availablefunctions. The output of this function to the responsive assets candepend upon the control method the utility has established for thatresponsive asset:

-   -   Direct demand response—an event-type of response is initiated by        the responsive asset system when the transactive incentive        signal exceeds a rather extreme threshold. Events occur        infrequently.    -   Time-of-use—an event is initiated by the responsive asset system        while the transactive incentive signal is within defined        boundaries that are exceeded most days. Often used to address        system peak load. Includes peak responses where more extreme        events are recognized.    -   Real-time—a continuum of responses is provided by the responsive        asset to the transactive incentive signal. This use case is        active most, if not all, days and hours.

These responses are shown conceptually in graph 2100 of FIG. 21.Relative variations in the transactive incentive signal are shown toresult in direct demand response, time-of-use (TOU), and real-timeresponse options.

4.5.5 Supply Transactive Node

A supply transactive node function is shown in diagram 2200 of FIG. 22and is similar to a load transactive node function. Both function typesattempt to mitigate an imbalance between electrical supply and load, soit is reasonable that their forms would be similar.

This transactive node function is targeted mostly to bulk generationnodes. At these transactive nodes, the base foundation for transactiveincentive signals is established. At a supply node, there may be noupstream nodes from which input transactive incentive signals could bereceived. The function in the path of the output transactive incentivesignal is then the initial formulation of the base transactive incentivesignal.

Local situational information can be generated or received by thistransactive node. The supply transactive node can apply supply control(or a recommendation) if such supply generation is provided at thistransactive node. Local information can also be used to inform what fuelexpense and other operational expenses should be included into theinitial transactive incentive signal at this location.

The incentive signal and the actual expenses of the supply desirablyagree over long periods of time, but the function can (while adhering tothis stated guideline) address the value of electrical generation in away that instills useful responses by the region's responsive assets.For example, when this supply transactive node function is applied atwind farms, the created transactive incentive signal can induce theregion's responsive assets to consume more of its energy while and nearwhere the wind energy is produced.

4.6 Understanding Generalized Transactive Nodes as Combinations of theFunctional Component Types

A set of transactive node functions has been introduced. These functionscan be generalized as shown in diagram 2300 of FIG. 23. In particular,diagram 2300 illustrates a single model of a transactive node and itsfunctions. Any one or more aspects of this model can be replicatedthroughout a transactive control and coordination system to represent avariety of types and instantiations of the system's transactive nodes.

In particular implementations of the transactive system, the outputtransactive incentive signal becomes an input transactive incentivesignal to a transactive node that is immediately downstream; the outputtransactive feedback signal from a transactive node becomes the inputfor a transactive node immediately upstream.

4.7 Hierarchy

Block diagram 200 in FIG. 2 shows examples of significant transactivenode locations that exist within a typical electric power grid.Embodiments of the transactive control technique are unique in that itaddresses the power system from bulk generation to end use and backagain. Ideally, and in certain embodiments, a complete hierarchy oftransactive nodes is defined throughout the power system. In reality,there are parts of the electrical connectivity pathways withouttransactive nodes. In such cases, some nodes will perform moreprediction and do so for more of a distribution system than they woulddo in a complete hierarchy. Further, in some cases, local constraintsand other local operation objectives that might be mitigated bytransactive nodes will remain unobserved.

5 Generalized Methods and Systems for Implementing Aspects of theDisclosed Technology

Having introduced the disclosed technology in the sections, this sectionpresents general methods and systems for performing aspects of thedisclosed transactive control approach. The embodiments below should notbe construed as limiting and can be performed alone or in combinationwith any other feature or aspect disclosed herein.

FIG. 24 is a flowchart 2400 showing a generalized method for operating atransactive node in a transactive control electrical-energy-allocationsystem as can be used in any of the disclosed embodiments. The methodcan be performed using computing hardware (e.g., a computer processor ora specialized integrated circuit). For instance, the method can beperformed by computing hardware associated with a transactive node whereelectrical energy is distributed, generated, and/or consumed.

At 2410, incentive signal data is computed. The incentive signal datacan comprise data indicative of a cost of electric energy at thetransactive node at a current time interval and data indicative of aforecasted cost of electric energy at the transactive node at one ormore future time intervals. In certain embodiments, the current timeinterval refers to the imminent (or next-to-occur) interval in which thetransactive node will operate.

At 2412, feedback signal data is computed. The feedback signal data cancomprise data indicative of an electric load at the transactive node atthe current time interval and data indicative of a forecasted load forelectric energy at the transactive node at the one or more future timeintervals. In certain embodiments, the current time interval refers tothe imminent (or next-to-occur) interval in which the transactive nodewill operate

At 2414, the incentive signal data and the feedback signal data istransmitted. For example, the incentive signal data and feedback signalcan be transmitted separately or together from one transactive node toeach of its neighboring transactive nodes.

In certain embodiments, the data indicative of the cost of electricenergy comprises data indicative of a cost of real electrical energy,reactive electrical energy, or a combination of both real and reactiveelectrical energies at the transactive node at the current timeinterval. Further, the data indicative of the forecasted cost ofelectric energy can comprise data indicative of a forecasted cost ofreal electrical energy, reactive electrical energy, or a combination ofboth real and reactive electrical energies at the transactive node atthe one or more future time intervals. In some embodiments, the dataindicative of the electric load comprises data indicative of a realelectrical load, reactive electrical load, or a combination of both realand reactive electrical loads at the transactive node at the currenttime interval. Further, the data indicative of the forecasted load forelectric energy can comprise data indicative of a forecasted load ofreal electrical load, reactive electrical load, or a combination of bothreal and reactive electrical loads at the transactive node at the one ormore future time intervals.

In some embodiments, the incentive signal data further comprises dataindicating a confidence level that the data indicative of the cost ofelectric energy at the transactive node at the current time interval isreliable (e.g., a confidence level for each time interval), and dataindicating a confidence level that the data indicative of the forecastedcost of electric energy at the transactive node at the one or morefuture time intervals is accurate (e.g., a confidence level for eachtime interval). Further, in certain embodiments, the feedback signaldata further comprises data indicating a confidence level that the dataindicative of the electric load at the transactive node at the currenttime interval is accurate, and data indicating a confidence level thatthe data indicative of the forecasted load for electric energy at thetransactive node at the one or more future time intervals is accurate.

In certain embodiments, the method further comprises receiving incentivesignal data and feedback signal data from one or more neighboringtransactive nodes. In such embodiments, the computation of the incentivesignal data can be based at least in part on the received incentivesignal data, and/or the computation of the feedback signal data can bebased at least in part on the received feedback signal data.

FIG. 25 is a flowchart 2500 showing another generalized method foroperating a transactive node in a transactive controlelectrical-energy-allocation system as can be used in any of thedisclosed embodiments. The method can be performed using computinghardware (e.g., a computer processor or a specialized integratedcircuit). For instance, the method can be performed by computinghardware associated with a transactive node where electrical energy isdistributed, generated, and/or consumed.

At 2510, incentive signal data is received at the transactive node fromtwo or more neighboring transactive nodes. The incentive signal datafrom the two or more neighboring transactive nodes can comprise dataindicative of at least a cost of electric energy at a current timeinterval. In certain embodiments, the incentive signal data comprisesdata indicative of the cost of electric energy at the current timeinterval (e.g., the delivered unit cost of the energy at that node) anddata indicative of a forecasted cost of electric energy at one or morefuture time intervals. In certain embodiments, the current time intervalrefers to the imminent (or next-to-occur) interval in which thetransactive node will operate

At 2512, aggregated incentive signal data is computed based at least inpart on the incentive signal data from the two or more neighboringtransactive nodes. In some embodiments, the aggregated incentive signaldata comprises data indicative of the aggregated cost of electric energyat the current time interval and data indicative of a forecastedaggregated cost of electric energy at one or more future time intervals.Further, in some embodiments, the aggregated incentive signal datacomprises a weighted sum of the incentive signal data from the two ormore neighboring transactive nodes. In certain embodiments, theaggregated incentive signal data is further modified to provide anincentive or disincentive to the further transactive node based on localconditions at the transactive node. In certain embodiments, the currenttime interval refers to the imminent (or next-to-occur) interval inwhich the transactive node will operate

At 2514, the aggregated incentive signal data is transmitted to afurther transactive node (e.g., a neighboring transactive node).

In some embodiments, the received incentive signal data and thetransmitted aggregated incentive signal data comprise data indicative ofa cost of real electrical energy, reactive electrical energy, or acombination of both real and reactive electrical energies. In certainembodiments, the received incentive signal data further includes dataindicating a confidence level of the received incentive signal data(e.g., a confidence level for each time interval). And in someembodiments, the transmitted incentive signal data further includes dataindicating a confidence level of the transmitted incentive signal data(e.g., a confidence level for each time interval).

In some embodiments, the method further comprises receiving feedbacksignal data at the transactive node from the two or more neighboringtransactive nodes, the feedback signal data from the two or moreneighboring transactive nodes comprising data indicative of at least anelectric load for electric energy at a current time interval; computingaggregated feedback signal data based at least in part on the feedbacksignal data from the two or more neighboring transactive nodes; andtransmitting the aggregated feedback signal data to the furthertransactive node. In such embodiments, the received feedback signal datacan comprise data indicative of the electric load for electric energy atthe current time interval and data indicative of a forecasted load ofelectric energy at the one or more future time intervals, and theaggregated feedback signal data can comprise data indicative of theaggregated load of electric energy at the current time interval and dataindicative of a forecasted aggregated load of electric energy at one ormore future time intervals.

FIG. 26 is a flowchart 2600 showing another generalized method foroperating a transactive node in a transactive controlelectrical-energy-allocation system as can be used in any of thedisclosed embodiments. The method can be performed using computinghardware (e.g., a computer processor or a specialized integratedcircuit). For instance, the method can be performed by computinghardware associated with a transactive node where electrical energy isdistributed, generated, and/or consumed.

At 2610, feedback signal data is received at a transactive node from twoor more neighboring transactive nodes. The feedback signal data from thetwo or more neighboring transactive nodes can comprise data indicativeof at least an electric load for electric energy at a current timeinterval. In certain embodiments, the received feedback signal datacomprises data indicative of the electric load of electric energy at thecurrent time interval and data indicative of a forecasted load ofelectric energy at one or more future time intervals. In certainembodiments, the current time interval refers to the imminent (ornext-to-occur) interval in which the transactive node will operate

At 2612, aggregated feedback signal data is computed based at least inpart on the feedback signal data from the two or more neighboringtransactive nodes. In certain embodiments, the aggregated feedbacksignal data comprises data indicative of the aggregated load of electricenergy at the current time interval and data indicative of a forecastedaggregated load of electric energy at the one or more future timeintervals.

At 2614, the aggregated feedback signal data is transmitted to a furthertransactive node.

In certain embodiments, the received feedback signal data and thetransmitted aggregated feedback signal data comprise data indicative ofa real electrical load, reactive electrical load, or a combination ofboth real and reactive electrical loads. In some embodiments, thereceived feedback signal data further includes data indicating aconfidence level of the received feedback signal data (e.g., aconfidence level for each time interval). And in certain embodiments,the transmitted feedback signal data further includes data indicating aconfidence level of the transmitted feedback signal data (e.g., aconfidence level for each time interval).

In some embodiments, the method further comprises receiving incentivesignal data at the transactive node from the two or more neighboringtransactive nodes, the incentive signal data from the two or moreneighboring transactive nodes comprising data indicative of at least acost of electric energy at the current time interval; computingaggregated incentive signal data based at least in part on the incentivesignal data from the two or more neighboring transactive nodes; andtransmitting the aggregated incentive signal data to the furthertransactive node. In such embodiments, the received incentive signaldata can comprise data indicative of the cost of electric energy at thecurrent time interval and data indicative of a forecasted cost ofelectric energy at the one or more future time intervals, and theaggregated incentive signal data can comprise data indicative of theaggregated cost of electric energy at the current time interval and dataindicative of a forecasted aggregated cost of electric energy at one ormore future time intervals.

FIG. 27 is a flowchart 2700 showing another generalized method foroperating a transactive node in a transactive controlelectrical-energy-allocation system as can be used in any of thedisclosed embodiments. The method can be performed using computinghardware (e.g., a computer processor or a specialized integratedcircuit). For instance, the method can be performed by computinghardware associated with a transactive node where electrical energy isdistributed, generated, and/or consumed. The method can be performed fora transactive node associated with one or more electric resources, oneor more electric loads, or a combination of both electric resources andloads.

At 2710, one or more functions from a library of functions are selected.The selection can be based at least in part on the type of one or moreelectric resources or electric loads associated with the transactivenode. In certain embodiments, the selected one or more functions areadapted for the type of electrical load or electrical supply associatedwith the transactive node. In some embodiments, the configuringcomprises causing computing hardware used to implement the transactivenode to execute a software program for performing computations using theselected one or more functions. In certain embodiments, the selected oneor more functions include a function that computes data representing oneor more of energy, an energy cost, or an incentive for one or moreelectric resources associated with the transactive node. In someembodiments, the selected one or more functions include a function thatcomputes data representing one or more of a predicted inelastic load orchanges in elastic load for one or more electric loads associated withthe transactive node

At 2712, the transactive node is configured to compute transactivesignals using the selected one or more functions.

In some embodiments, the method can comprise accessing a databasestoring the library of functions (e.g., a locally stored database or adatabase remotely located from the transactive node).

Further, the library of functions can be an extensible library. Forexample, the library can be expanded to include newly formulatedfunctions. Further, in some implementations, existing functions may beselected from the library, edited by a relevant party (e.g., a utilityor system administrator), and returned to the library as a newlyavailable function with modified features and capabilities. The partiesthat have access to editing and adding library functions can vary fromimplementation to implementation, and can encompass a wide variety ofparties involved in the power transmission infrastructure. In someinstances, the parties who can edit and/or add functions is limited tosome selected group (e.g., system regulators or to a single utility).

Also disclosed herein are several embodiments for systems fordistributing electricity. One of the disclosed systems is a system fordistributing electricity, comprising: a plurality of transactive nodes,each transactive node being associated with one or more electricresources, one or more electric loads, or a combination of one or moreelectric resources and loads; and a network connected to the transactivenodes to facilitate communication between the transactive nodes. Inthese embodiments, the transactive nodes are configured to exchangeincentive and feedback signals with one another in order to determine anelectrical demand in the system for a current time interval and toprovide an electrical supply sufficient to meet the electrical demandfor the current time interval. In certain embodiments, the current timeinterval refers to the imminent (or next-to-occur) interval in which thetransactive nodes will operate

In certain embodiments, the transactive nodes are further configured toexchange incentive and feedback signals for two or more future timeintervals in addition to the incentive and feedback signals for thecurrent time interval. In some embodiments, the two or more future timeintervals have increasingly coarser granularity. In certain embodiments,at least one of the transactive nodes modifies one or both of itsincentive or feedback signals in response to previously receivedincentive and feedback signals. In some embodiments, the at least one ofthe transactive nodes is associated with an elastic load, and whereinthe modified incentive or feedback signals corresponds to a predictedchange in the elastic load. In certain embodiments, the at least one ofthe transactive nodes is associated with an electrical resource, and themodified incentive or feedback signals corresponds to a change in theelectrical resource. In further embodiments, the at least one of thetransactive nodes is associated with an electrical resource, and themodified incentive signals correspond to a change in local conditions.

In certain embodiments, one or more of the transactive nodes computetheir respective incentive and feedback signals using functions selectedfrom a library of functions. Still further, in some embodiments, theincentive and feedback signals further include confidence level dataindicating a respective reliability of the incentive and feedbacksignals.

Another system disclosed herein is a system for distributingelectricity, comprising: a plurality of transactive nodes, eachtransactive node being associated with one or more electric resources,one or more electric loads, or a combination of one or more electricresources and loads; and a network connected to the transactive nodesand facilitating communication between the transactive nodes. In theseembodiments, the transactive nodes are configured to exchange sets ofsignals with one another in order to determine an electrical demand inthe system for a current time interval and to provide an electricalsupply sufficient to meet the electrical demand for the current timeinterval. Each set of signals includes signals for determining theelectric loads and supplies for the current time interval as well assignals for determining the electric loads and supplies for two or morefuture time intervals. In certain embodiments, the current time intervalrefers to the imminent (or next-to-occur) interval in which thetransactive nodes will operate

In some embodiments, the future time intervals have increasingly longerdurations as the time intervals are farther into the future relative tothe current time interval. In other embodiments, the transactive nodesare configured to update the values of the sets of signals at an updatefrequency, the update frequency corresponding to a duration of thecurrent time interval. In some embodiments, the transactive nodes areconfigured to exchange the set of signals with one another iterativelyover time such that the signals for a respective time interval stabilizeas the respective time interval approaches the current time interval.

In certain embodiments, the transactive nodes are configured to exchangethe set of signals with one another on an asynchronous event-drivenbasis or a clock-driven basis. In some embodiments, a respective set ofthe transactive nodes are configured to iteratively exchange a set ofsignals with one another until the exchanged set of signals converges towithin an acceptable degree of tolerance. In certain embodiments, atransactive node in the respective set of the transactive nodes isfurther configured to transmit an updated set of signals when localconditions at the transactive node cause the updated set of signals todeviate from a previously transmitted set of signals beyond a relaxationcriterion. In some embodiments, the sets of signals further includeconfidence level data indicating a respective reliability of theexchanged signals (e.g., a confidence level for each time interval).

Another system disclosed herein is a system for distributingelectricity, comprising: a plurality of transactive nodes, eachtransactive node being associated with one or more electric supplies,one or more electric loads, or a combination of one or more electricsupplies and loads; and a network connected to the transactive nodes andfacilitating communication between the transactive nodes. In theseembodiments, the transactive nodes are configured to exchange sets ofsignals with one another in order to determine an electrical demand inthe system for a current time interval and to provide an electricalsupply sufficient to meet the electrical demand for the current timeinterval, a respective one of the transactive nodes being configured tocompute its incentive and feedback signals using one or more functionsselected from a library of functions. In certain embodiments, thecurrent time interval refers to the imminent (or next-to-occur) intervalin which the transactive nodes will operate

In certain embodiments, the one or more functions selected from thelibrary of functions are selected based on the type and number ofelectrical supplies and electrical loads with which the respectivetransactive node is associated. The one or more functions can beselected from a group of resource functions comprising one or more of:(a) a resource function adapted to account for imported electricalenergy, (b) a resource function adapted to account for a renewableenergy resource, (c) a resource function adapted to account for fossilfuel generation, (d) a resource function adapted to account for generalinfrastructure cost, (e) a resource function adapted to account forsystem constraints, (f) a resource function adapted to account forsystem energy losses, (g) a resource function adapted to account fordemand charges, and (h) a resource function adapted to account formarket impacts. The one or more functions can also be selected from agroup of load functions comprising one or more of: (a) a load functionadapted to account for a bulk inelastic load, (b) a load functionadapted to account for an event-driven demand response, (c) a loadfunction adapted to account for a time-of-use demand response, and (d) aload function adapted to account for a real-time continuum demandresponse.

In some embodiments, the respective one of the transactive nodescontrols one or more elastic loads and adjusts the one or more elasticloads in response to the feedback and incentive signals received at therespective one of the transactive nodes. In certain embodiments, the oneor more functions are implemented by individual software modules thatcan be combined with one another to implement the desired transactorbehavior for the respective one of the transactive nodes.

In certain embodiments, through the use of the one or more functions,the respective one of the transactive nodes computes a control signalselected from a set of signed whole numbers and communicates thecomputed control signal to one or more loads, resources, or loads andresources associated with the respective one of the transactive nodes.The computed control signal can be interpreted by an electricalgenerator or set of electrical generators as a fraction of thegenerator's or generators' rated generation capacity. The computedcontrol signal is interpreted by an electrical load or set of electricalloads as a fraction of the load's or loads' rated power.

It should be understood that in embodiments of the disclosed technology,a transactive node may host multiple toolkit functions, including anycombination of multiple resource and incentive functions, multiple loadfunctions, or combinations of both resource and incentive and loadfunctions. For instance, the resource and/or incentive functions used ata transactive node will typically depend on the location of thetransactive node in a power grid topology, and on the one or moreresources and/or loads for which the transactive node is responsible.This ability to “mix and match” resource and incentive functions whilestill maintaining a common transactive signal communication structuregives embodiments of the disclosed technology wide flexibility andscalability for implementing a transactive control system.

6 Further Details and Embodiments

Having introduced the disclosed technology, this section includes foursupplemental Appendices that provide additional details andconfigurations that can be used in implementations of the technology.The specific implementations disclosed below should not be construed aslimiting. Further, any one or more of the features or aspects disclosedbelow can be used alone or in conjunction with any other feature oraspect of the disclosed technology discussed herein. Some portions ofthe appendices may, in some instances, be repetitive to other portionsof this application, but such portions are included for the sake ofcompleteness.

6.1 Appendix A—Transactive State Model 6.1.1 Purpose

A transactive control and coordination system is a network of looselyconnected, interacting transactive nodes. This appendix states ahigh-level state model for a transactive node and types of connectionsthat a transactive node desirably manages. This appendix should providevaluable guidance to system designers who are implementing a transactivecontrol and coordination system from the perspective of a transactivenode.

This appendix defines and discusses

-   -   example attributes of a transactive node and four example types        of connections    -   the organization of these attributes into groups—transactive        node, general connection, transactive neighbor, system manager,        asset, and local information    -   example allowed states within the high-level transactive node        state model    -   example functions and events by which attributes become changed        and by which the states are navigated in this state model    -   example state transition tables and diagrams for the respective        transactive node and its connections.

6.1.2 Structure

In some embodiments, a transactive node manages its own set ofattributes and additionally manages additional types of connection. Incertain implementations the transactive node manages four types ofconnections—connections to transactive neighbors, system managers,assets, and local input information. All four connection types can sharea set of connection attributes in common in order to manage connectionsbetween this transactive node and each transactive neighbor, systemmanager, asset, or local input information. An example of this structurehas been laid out in diagram 2800 in FIG. 28.

6.1.3 Transactive Node States and State Diagram

In certain embodiments, a transactive node has five states available toit as shown in the state transition diagram 2900 of FIG. 29:

-   -   1—New or Terminated—initial and terminal state where the        transactive node attributes are not defined. The transactive        node leaves and returns to this state by running or terminating        an executable program.    -   2—Under Local Control—intermediate state where the transactive        node executable process is up and running, but the transactive        node and its connections are not adequately configured. Few, if        any, of this transactive node's connections have been completed        between this transactive node and its transactive neighbors,        system managers, assets, or local information sources, which        collectively will be referred to as the transactive node's        “connection partners.” A transactive node enters this state when        a transactive node executable program is run or when a        Configuration Test fails.    -   3—Configured—intermediate state where certain transactive node        attributes (those transactive node attributes having asterisks        in FIG. 28) have been defined and each of the connections that        this transactive node manages is also in its Configured state. A        transactive node enters this state by passing a Configuration        Test or by failing a Connection Test.    -   4—Connected & Configured—a transactive node state that has been        Configured and now each of the connections that this transactive        node manages is in its Connected (or temporarily in its Lost        Connection) state. A transactive node enters this state by        passing a Connection Test, by receiving and accepting a Halt        Operations command, or by encountering a Fatal Operational        Event.    -   5—Operational—a transactive node that has been Connected &        Configured and which now interacts with its connection partners        according to its algorithmic responsibilities of membership in a        transactive control and coordination system. The algorithmic        responsibilities are addressed elsewhere as a “toolkit        framework” of computational algorithms and a suite of “toolkit        library functions” that may be incorporated to represent the        more unique and individual algorithmic responsibilities of        transactive nodes. The toolkit framework and the toolkit library        functions are described in more detail in Appendices B and C. A        transactive node enters this state by receiving and accepting an        Operate command.

The identifying numbers that have been applied to the functions andevents in FIG. 29 are derived from the prior and end states. A letter isappended wherever multiple functions or events achieve the same statetransition. For example, the function numbered “54b” (e.g., a HaltOperations command in FIG. 29), is the second state transition that hasbeen defined from state “5” to state “4.” These same function and eventnumbers will be used in corresponding state transition table.

6.1.4 Connection States and State Diagram

Each connection has four allowed states as shown in diagram 3000 of FIG.30. The only details that really change between the four types ofconnections are those attributes that are tested if a ConnectionConfiguration Testis to be passed for a given connection. These are theconnection states and their descriptions:

-   -   1—Listed—a connection has been listed when its identifier        appears among those in any of these corresponding connection        attribute lists:        -   49—List of Transactive Neighbors (a transactive node            attribute)        -   50—List of System Managers (a transactive node attribute)        -   51—List of Assets (a transactive node attribute)        -   38—List of Local Information Connections (an asset            connection attribute)    -   There is no expectation that any of the corresponding attributes        have been configured in this state. A connection reaches this        state by becoming listed in one of the attributes above, which        may occur as a transactive node executable program is being run        or thereafter using the Configure command. This is an initial        and terminal state of any connection.    -   2—Configured—certain attributes (see asterisks in FIG. 28) of        this connection have been configured and are not empty. This        connection enters this state by passing a Connection        Configuration Test, by accepting a Disconnect command that has        been directed to this connection, or when a Terminate Connection        Event occurs after this connection has been in its Lost        Connection state, which event indicates that either a timeout        duration has expired or that too many Loss of Connection Events        have occurred in the past hour or day. This is an intermediate        state.    -   3—Connected—a communication link (a “connection”) has become        successfully established between this transactive node and one        of its connection partners via this connection. A connection        enters this state by receiving and accepting a Connect command        or by having the connection re-established from a Lost        Connection state by a Connect command or a Re-Establish        Connection Event. This is an intermediate state, but a        connection should be expected to remain in this state most of        the time.    -   4—Lost Connection—the state of a connection while the connection        between this transactive node and one of its connection partners        via this connection has become broken or severed. This temporary        intermediate state may be entered by a connection only by a Loss        of Connection Event. The connection should thereafter be either        re-established by a Connect command or Re-Establish Connection        Event, or the connection should become disconnected by a        Disconnect command or by a Terminate Connection Event.

Again, the identifying numbers and letters that prepend the functionsand events in FIG. 30 are derived from prior and end states and will beused also to identify these same transitions in state transition tables.

6.1.5 The Meaning of Attribute Dictionary Columns

Table 7 is a dictionary of example attributes that can be used to definethe state of a transactive node. Later in this appendix, attributedictionaries will be presented to address attributes of the four typesof connections. The meanings of the columns in these dictionary tablesare as follows.

-   -   Attribute—structured list of attributes (properties,        characteristics) defines the pertinent properties of a class of        objects. Assigning specific values to the full set of        attributes, creates a specific instance or member of the class.        Grouping certain attributes into subsets defines the states of        an object, including a single start state, one or more        intermediate states, and one or more final states.    -   Attribute Name—a string of alphanumeric (alphabetic, numeric)        and possibly special characters given to the attribute for        reference.    -   Description—an easy-to-read narrative about the attribute,        clearly distinguishing it from other attributes.    -   Role—the reason the attribute is important for: 1) the        definition of an object, and 2) the application of an attribute        in the process that directs actions to instantiate a specific        object.    -   Type—the attribute may represent a type of number, character        string, a pointer to a procedure, set of algorithms, names of        other classes, an address, or an array of types.    -   Format—the specific arrangement of the characters or the parts        of the assigned attribute value(s).    -   Range of Values—the specific set of values a process may assign        to an attribute, such as least value and greatest value for        numbers.    -   Security—the level of security assigned to an attribute, the        identification of the entities (people, systems) authorized to        access an attribute, and whether the entities have the right        only to read the value of the attribute or to both read and        write the attribute value(s).

6.1.6 Transactive Node Attribute Dictionary

The transactive node attribute group contains those attributes thatstand alone and refer to one transactive node and its transactive nodestate model. An example attribute dictionary is shown in Table 7.

Table 8 that follows is a summary of which of these attributes can beadded, checked, or modified by the set of commands and events that occurwithin the state transition table (Table 7), as were introduced in thestate transition diagram 2900 of FIG. 29.

TABLE 7 Dictionary of the Transactive Node Attributes Attribute Range ofNo. Name Description Role Type Format values 1 Node ID Unique ID ThisCharacter 0-9, A-Z See topology of this transactive string Example: forthe transactive node's name “UT-01” transactive node. that may becontrol and used to refer coordination to it. system This is a whereattribute that transmission is desirably zone, found to balancing havebeen authority, configured utility, and during site names Configurationhave been Tests. stated. 3 Node The type of Character TZ, BA, UT, Typetransactive string ST control node. Four types have been identified:Transmission Zone (TZ) Balancing Authority (BA), Utility (UT), Site (ST)4 Geographical The Perhaps (latitude, (−90 to 90, 0-360) Locationrepresentative useful for longitude) degrees of Node physical futureglobal (-pi to pi, 0-2 * location of information pi) radians this system(GIS) Default transactive representations. value: node. (null, null) 5Node The To keep Two “Filename, “Filename” Version* implementation trackof alphanumeric ##.##”, should be an version successions items where##.## allowable for the of software are the executable instantiatedduring major and filename. transactive incremental minor “##.##” majornode at the improvements, version and minor time the troubleshooting,numbers of versions Run Node testing. this file, anticipated ExecutableThis is an respectively. from “0.00” command is attribute that to“99.99”. issued. is desirably This found to executable have been fileconfigured represents during a “version” Configuration for the Tests.transactive node overall. 7 Node The state of Unambiguous SingleExample: “1” “1” - New or Status* this representation integerTerminated, transactive of the state “2” - Under node within of thisLocal this state transactive Control, “3” - model. node withinConfigured, this state “4” - model. Connected & This is an Configured,attribute that “5” - Operational is desirably found to have beenconfigured during Configuration Tests. 8 Mode The current Single“Experimental”, mode of character “Production”, operation. string “Test”9 Update The The update Single Integer From 1 to Frequency* frequencyfrequency integer Example: 3600. The used to may change “12”Demonstration update TIS between will most and TFS. testing and oftenuse Units are operation. “12”, “updates This is an meaning one perhour”. attribute that update is is desirably performed found to every 5have been minutes. configured during Configuration Tests. 16 ElectricalThe logical Character Varied Varied Topology location of a stringLocation transactive node in an electrical system 18 Time* Present Timeis used See UTC See UTC time in UTC to mark standard. standard Format.when node Time is state coordinated transitions across the occur andsystem of also to transactive support nodes to timing of within 500events milliseconds, related to or so. 9 - Update Frequency. Eachtransactive node calculates transactive signal interval start timesstarting from this, the present time. This is an attribute that isdesirably found to have been configured during Configuration Tests. 21Processing The time The time Varied Varied Varied Time delay for delayis used Delay this node to manage within the the time processingsequence time interval relationships for the system of transactivecontrol nodes 22 Time Out The time to If expected Varied Varied Variedwait for TIS/TFS receipt of are not TIS and received TFS from before theadjacent time out then nodes the node proceeds with availableinformation and reports an associated change in data quality values 34Resource A storage See toolkit List of Expected to Reasonable Scheduleslocation framework. series. The be very ranges may and Cost describedThis storage individual similar to be asserted. Buffer in the toolkitlocation has records will TIS and framework. data that is probably TFS.Records of relevant to resemble See the this storage the TIS and toolkitlocation formulation TFS. See framework. possess of both the toolkitinformation TIS and framework. about TFS. resources and incentives, mostof which are being applied via toolkit functions. 38 Current The seriesA storage One series See the See toolkit IST Series of interval locationof times toolkit framework. Buffer start times described in using UTCframework. The (IST) that the toolkit standard. Series of Demonstrationhave been framework. See toolkit times in has calculated An interimframework. UTC defined 56 and will be data storage standard intervals.used to location format. The intervals define the within the can alignintervals of toolkit with one of transactive framework. the 12 majorsignals that Refer to the division of an are being toolkit hour.formulated. framework. 39 Input A storage Holding List of TIS See Referto Transactive location place for and TFS transactive range Signalsdescribed most recent (e.g., a list signal attributes of Buffer in thetoolkit transactive of series). formats and TIS and TFS. framework.signals that See toolkit XML Records have been framework. schema.include at received. least the Holds at most least recently attributesreceived 23 - Receive transactive TIS Buffer signals. and 24 - ReceiveTFS Buffer, but may also retain records of prior examples. An interimdata storage location within the toolkit framework. Refer to the toolkitframework. 40 Resource A storage Place where List of Various. SeeVarious for and location the input various the toolkit records thatIncentive described “other local items and framework. should be Input inthe toolkit conditions” series data See defined in Buffer framework.that will be as should individual toolkit invoked by be defined toolkitfunctions. resource and for each resource incentive toolkit and toolkitresource incentive functions and functions, should be incentive wherethe held and function. contents and managed. Refer to formats Attributetoolkit should be 25 - Local resource specified. Information and Sourceincentive states the functions sources that that are should used atsupply the this contents of transactive this storage node location.where An interim these data storage specifications location shouldwithin the be made. toolkit framework. Refer to the toolkit framework.41 Load A storage Place where List of Various. See Various for Functionlocation the input various the toolkit records that Input described“other local items and framework. should be Buffer in the toolkitconditions” series data See defined in framework. that will be as shouldindividual toolkit invoked by be defined toolkit load functions. loadtoolkit for each functions, functions toolkit load where the should befunction. contents and held and Refer to formats managed. toolkit loadshould be Attribute functions specified. 25 - Other that are Local usedat Conditions this Source transactive states the node sources that whereshould these supply the specifications contents of should this storagebe made. location. An interim data storage location within the toolkitframework. Refer to the toolkit framework. 42 Output A storage The OneTIS See TIS See range TIS Buffer location formulated attributes ofdescribed TIS is held TIS in the toolkit here and framework. may bePlace replaced and where further updated updated until TIS is held it isfinally until it can distributed to be transactive distributed.neighbors (and maybe other entities). See attribute 12 - Send TISTargets. An interim data storage location within the toolkit framework.Refer to the toolkit framework. 43 Output A storage The One TFS. See TFSSee range TFS location formulated attributes of Buffer described TFS isheld TFS in the toolkit here and framework. may be Place replaced andwhere further updated updated until TIS is held it is finally until itcan distributed to be transactive distributed. neighbors (and maybeother entities). See attribute 13 - Send TFS Targets. An interim datastorage location within the toolkit framework. Refer to the toolkitframework. 44 Total A storage Sum of List of Modeled RepresentsPredicted location average series. after, or total average Resourcedescribed power that is Contents identical to, generated Buffer in thetoolkit generated should be a TFS power and framework. within or similarto format. imported imported into TFS with power during a transactivesame an interval. node during format. Reasonable future ranges canintervals. be stated, Compared but there is against total no such testload during in the the present formulation model. of TFS series. Aninterim data storage location within the toolkit framework. Refer to thetoolkit framework. 45 Inelastic A storage Records are List of ModeledRecords of Load location the inelastic series. after, or this listPrediction described load Contents identical to, represent the Buffer inthe toolkit predicted should be a TFS load being framework. from onesimilar to format. modeled by toolkit load TFS with a toolkit loadfunction for same function. future format. Reasonable intervals. rangescan Used to be stated, predict total but there is load at future no suchtest intervals. in the An interim present data storage model. locationwithin the toolkit framework. Refer to the toolkit framework. 46 ElasticA storage Records are List of Modeled Records of Load location thechanges series. after, or this list Prediction described to elasticContents identical to, represent the Buffer in the toolkit load that areshould be a TFS change in framework. predicted similar to format.elastic from one TFS with component toolkit load same of a load thatfunction for format. is being future modeled by intervals. a toolkitload Used to function. predict total Reasonable load at future rangescan intervals. be stated, An interim but there is data storage no suchtest location in the within the present toolkit model. framework. Referto the toolkit framework. 47 Predicted A storage An interim List ofModeled Records of Inelastic location data storage series. after, orthis list and described location Contents identical to, representElastic in the toolkit within the should be a TFS total load of Loadframework. toolkit similar to format. a transactive Buffer An interimframework. TFS with node. data Refer to the same Reasonable storagetoolkit format. ranges can location framework. be stated, within the Aninterim but there is toolkit data storage no such test framework.location in the Refer to the within the present toolkit toolkit model.framework. framework. Refer to the toolkit framework. 49 List of List ofThis Comma- Example #1: See system Transactive transactive transactiveseparated “UT06”, topology. Neighbors nodes with node list of which isthe List should which this declares character Demonstration's includetransactive transactive strings identifier for nearby node neighbors antransactive exchanges that it plans demonstration nodes with electricalto interact utility. which this energy and with. A transactive willtransactive node expects therefore neighbor that to exchange exchangeappears on energy. transactive this list is Naming signals. eligible topractice enter its should be Listed state the same after its 52 - hereand for Transactive attribute 52 - Neighbor ID Transactive has becomeNeighbor ID, a configured. Transactive This attribute Neighbor ischecked attribute. during Configuration Tests and Connection Tests tosee if expected transactive neighbors have become Configured andConnected. 50 List of List of This is the Comma- Example #1: See systemSystem entities of a attribute by separated “EI01” to topology. Managerstransactive which this list of represent Naming control and transactivecharacter the system practice coordination node strings manager, shouldbe system declares from which the same that will be which system hereand for granted at entities it will management attribute least limitedallow to command 53 - System permission make will likely be Manager ID,to make system received. a System system management Example #2: Managermanagement commands. “UT06”, attribute. commands The system which is theto this managers Demonstration's transactive instantiate a identifierfor a node. A connection, demonstration system and this utility, managertransactive which may may be, but node be both a is not accepts a systemnecessarily, responsibility manager to also a to maintain thetransactive the transactive neighbor. connection nodes that it to eachowns and a system transactive manager. A neighbor, system too. managerin this list is eligible to enter its Listed state. For each Listedsystem manager, this transactive node should manage and monitor itsstate to enter either the 3 - Configured or 4 - Configured & Connectedtransactive node states, and for which Configuration Tests andConnection Tests are conducted. 51 List of List of This is the Comma-Example #1: See toolkit Assets generation attribute in separated “AV01”to framework. resources, which a list of represent an See incentives,transactive character asset respective and loads node strings system oftoolkit that are declares its Avista function for a engaged assets. EachUtilities. given asset. and used asset should Naming by this be practicetransactive accompanied should be node. by a toolkit the same functionthat here and for defines its attribute 2 - predicted Asset ID, anparticipation Asset in ways that attribute. affect transactive signalsthat are formulated at this transactive node. The assets listed here areeligible to enter their Listed states after attribute 2 - Asset ID hasbeen configured. This attribute is checked during Configuration Testsand Connection Tests to see if expected assets have become Configuredand Connected. 57 Interval An ordered This attribute Comma-Demonstration Integer Durations* list of along with separated example:values interval 58 - list of {5, 15, 60, between 1 durations in Numbersof integers 360, 1440}, and 1440. minutes Intervals that representing Anallowed that will be states the represent 5 minutes, number of used bythis durations of interval 15 minutes, series transactive the intervalsdurations 1 hour, 6 elements node as it that this in minutes hours, and1 may be formulates transactive day. The 1- specified in its node willday intervals the future but transactive represent in are most will notbe an signals. each of the distant into issue for the Order istransactive the future. Demonstration from first to signals that it Inthe above that will most calculates. example, the use only 5 distantinto The number last sample different the future. of series of eachinterval elements in duration has durations. this attribute a flexibleNote that this and in 58 - duration that approach Numbers of may varythat uses Intervals between the integer should be present and minuteswill identical at the following limit the the times durations. practiceof transactive This is done intervals that signals are to keep areshorter being intervals than 1 calculated. aligned with minute in theThis attribute hourly future. creates no market data. The numberexpectation of series that elements in transactive this attributeneighbors and in 58 - will have Numbers of used the Intervals sameshould be interval identical at durations. the times This transactivetransactive signals are node should being be quite calculated. flexiblein its ability to receive and interpret diverse time series information.58 Numbers An ordered This attribute Comma- Demonstration No explicit oflist of the along with separated example: limit has Intervals* number of57 - Interval list of {12, 20, 18, been placed each of the Durationsintegers 4, 2}, on the 57 - Interval states the that representingmagnitude of Durations number of represent that there each that will bethe intervals the will be 12 5- element; used by this of each number ofminute, 20 however, an transactive duration that each 15-minute, elementnode as it this corresponding 18 1-hour, 4 would formulates transactiveinterval 6-hour, and unlikely be its node will duration 2 1-day greaterthan transactive represent in that is intervals. 10,080 - the signals.each of the listed in The last number of Order is transactive 57 -member of minutes in a from first to signals that it Interval eachinterval week. most calculates. Durations. duration An allowed distantinto The number (e.g., the number of the future. of series 12^(th),32^(nd), series elements in 50^(th), and elements this attribute 54^(th)may be and in 57 - intervals) specified in Interval varies in the futurebut Durations duration will not be an should be between the issue forthe identical at durations of Demonstration the times the present thatwill transactive and next use only 5 signals are intervals. differentbeing interval calculated. durations. This attribute The number createsno of series expectation elements in that this attribute transactive andin 57 - neighbors Interval will have Durations used the should be sameidentical at intervals. the times This transactive transactive signalsare node should being be quite calculated. flexible in its ability toreceive and interpret diverse time series information.

TABLE 8 Ways in Which Transactive Node Attributes may be affected bythis State Model's Commands and Events Handle Run Node Halt TerminateCon- Con- Handle Fatal Non-Fatal Attribute Executable Configure OperateOperations Node figuration nection Operational Operational # AttributeName Command Command Command Command Command Test** Test** Event Event 1Node ID* ++ − C 5 Node Version* ++ − C 7 Node Status* (C)++ C0 C0 C0 C−C0 C0 C00 C 9 Update Frequency* + +0 − C (C) (C) 18 Time* + +0 − C (C)(C) 57 Interval Durations* + +0 − C 58 Numbers of Intervals* + +0 − C 49List of Transactive + +0 − C C Neighbors 50 List of System Managers + +0− C C 51 List of Assets + +0 − C C 34 Resource Schedules and + +0 − CostBuffer 38 Current IST Series + +0 − Buffer 39 Input TransactiveSignals + +0 − Buffer 40 Resource and Incentive + +0 − Input Buffer 41Load Function Input + +0 − Buffer 42 Output TIS Buffer + +0 − 43 OutputTFS Buffer + +0 − 44 Total Predicted Resource + +0 − Buffer 45 InelasticLoad Prediction + +0 − Buffer 46 Elastic Load Prediction + +0 − Buffer47 Predicted Inelastic and + +0 − Elastic Load Buffer 4 GeographicalLocation of + +0 − Node 3 Node Type + +0 − 8 Mode + +0 +0 +0 − +0 +0 16Electrical Topology + +0 − Location 21 Processing Time Delay + +0 − 22Time Out + +0 − (C) (C) *These Node attributes will be checked andshould be configured (not empty) during a Configuration Test. **TheConfiguration and Connection Tests will additionally check the Assetattribute 38 - List of Local Information and the statuses ofconnections. “C” = condition checked; “(C)” = condition possiblychecked; “++” = “should establish new attribute content”; “+” = “mayestablish new attribute content”; “−−” = “should remove existingattribute content; “−” = “may remove existing attribute content”; “00 =“should modify existing attribute content”; “0” = “may modify existingattribute content”

6.1.7 Functions and Events of the Transactive Node State Model

Run Node Executable(Filename) Command

-   -   Command Parameters        -   Filename—Filename that should be found in and run from a            known file directory. If Filename cannot be found, fail in            condition F1.    -   Command Logic        -   If Filename cannot be recognized or located, then reply            -   “Command failed—(F1) File could not be found”        -   If this transactive node is already running an executable            file, as can be determined by transactive node attribute            7—Node Status being in a valid, defined state or other            evidence that the executable is running, then reply            -   “Command failed—(F2) Node executable is already                running.”        -   If the entity that made this command is not the local system            manager and is not found to have been granted permission to            make this command by attribute 31—Connection Partner's            System Management Permissions, then reply            -   “Command failed—(F3) Lacking permission to make this                command”        -   If after running Filename the attributes 1—Node ID, 5—Node            Version, 7—Node Status, and 18—Time have not become            configured, then do not run the node executable. Reply            -   “Command failed—(F4) Critical transactive node                attributes were not configured”        -   If the node executable fails to run for any other reason,            reply            -   “Command failed—(F5) Unknown reason”        -   Otherwise,            -   The node executable runs to completion and its process                remains active, including the management present time                18—Time in UTC format.            -   Set attribute 7—Node Status=“2” (state 2—Under Local                Control).            -   Populate attributes 1—Node ID, 5—Node Version, and                18—Time with the contents supplied by Filename. These                attributes may not be empty at the successful conclusion                of this command.            -   Additionally, any other attribute may be populated at                the time the node executable is run.            -   Reply, “Command succeeded—(S1)”

Configure( )(Node Attributes) Command—a flexible command that isapplicable to the transactive node as well as to the other connectionsthat a transactive node manages. An important concept in the use of thiscommand is that the connection's identifier should be stated before anyof its attributes may be modified. Because this section is addressingonly the transactive node state model, the only attributes that will beaddressed in this section are transactive node attributes for thistransactive node.

-   -   Command Parameters        -   ConfigureFile=(Filename)—If a file is named using this            parameter, a command script will be read from Filename found            in a known file directory. It is recommended that Filename            should contain scripted parameters as would be used in line            with the command.        -   Any combination of the following comma-separated, in-line            command parameters may be used and in any order:        -   Node=(1—Node ID)—(Optional) Should match the identity of            this transactive node.            -   NodeAttribute=attribute #, attribute value 1[[,                attribute value 2], . . . ]—This parameter may be used                to initialize or change the contents of any Node group                attribute except attribute 1—Node ID, 5—Node Version,                7—Node Status, or 18—Time.    -   Command Logic        -   If the entity that made this command is not the local system            manager and if the entity has not been explicitly given            permission to make this system management command among the            commands in its 31—Connection Partner's System Management            Permissions, then reply            -   “Command failed—(F1) Permissions do not include this                command”        -   If attribute 7—Node Status=“5” (state 5—Operational), then            reply            -   “Command failed—(F2) Configure command not allowed from                Operational state.”        -   If Filename cannot be found, reply            -   “Command failed—(F3) File cannot be found or opened”        -   If the Node ID does not match the presently configured Node            ID, then reply            -   “Command failed—(F4) Incorrect node ID”        -   If the node attribute number does not match a known Node            attribute number (e.g., is not a member of {3, 4, 8, 9, 16,            21, 22, 34, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 49, 50            or 51}), then reply            -   “Command failed—(F5) Command did not address known node                attributes”        -   If the command cannot be completed for any other reason,            reply            -   “Command failed—(F6) Unknown reason”        -   Otherwise,            -   Reply, “Command succeeded—(S1)”            -   Finalize any changes to transactive node attributes that                were specified in the file or on the command line.            -   Run a Configuration Test.            -   Run a Connection Test.

Configuration Test( )—this is neither a system management command nor anevent, but it is a test of the present configuration that should beconducted automatically by a transactive node after a successfulConfigure( ) command. It is permissible that the test may be run moreoften, but the outcome should not be expected to change unless asuccessful Configure( ) command occurs.

-   -   Parameters—None.    -   Test Logic        -   If upon checking attribute 7—Node Status, this transactive            node is found to be in state “5” (5—Operational), then            -   Test passed—(S1) The Operational state is necessarily                Configured.            -   No further tests are required. No state transition                occurs. No attributes are changed.        -   If any of the attributes 1—Node ID, 5—Node Version, 7—Node            Status, 9—Update Frequency, 18—Time, 57—Interval Durations,            or 58—Numbers of Intervals have not yet been configured and            are therefore empty, then            -   Test failed—(F1) The transactive node is not configured.            -   Attribute 7—Node Status=“2” (state 2—Under Local                Control).        -   If for any transactive neighbor connection listed in 49—List            of Transactive Neighbors a corresponding 52—Transactive            Neighbor ID has not been established, then            -   Test failed—(F2) Not all transactive neighbors have been                Listed.            -   Attribute 7—Node Status=“2” (state 2—Under Local                Control).        -   If for any system manager connection listed in 50—List of            System Managers a corresponding 53—System Manager ID has not            been established, then            -   Test failed—(F3) Not all system managers have been                Listed.            -   Attribute 7—Node Status=“2” (state 2—Under Local                Control).        -   If for any asset connection listed in 51—List of Assets a            corresponding 2—Asset ID has not been established, then            -   Test failed—(F4) Not all assets have been Listed.            -   Attribute 7—Node Status=“2” (state 2—Under Local                Control).        -   If for any Listed transactive neighbor (e.g., one for which            a 52—Transactive Neighbor ID has become established) its            32—Connection Status is either undefined or “1” (connection            state 1—Listed), then            -   Test failed—(F5) Not all transactive neighbors have                become configured.            -   Attribute 7—Node Status=“2” (state 2—Under Local                Control).        -   If for any Listed system manager (e.g., one for which a            53—System Manager ID has become established) its            32—Connection Status is either undefined or “1″ (connection            state 1—Listed), then            -   Test failed—(F6) Not all system managers have become                configured.            -   Attribute 7—Node Status=“2” (state 2—Under Local                Control).        -   If for any Listed asset (e.g., one for which a 2—Asset ID            has become established) its 32—Connection Status is either            undefined or “1” (connection state 1—Listed), then            -   Test failed—(F7) Not all assets have become configured.            -   Attribute 7—Node Status=“2” (state 2—Under Local                Control).        -   If for any asset connection that has local information            connections listed in its 38—List of Local Information a            corresponding 52—Transactive Neighbor ID has not been            established, then            -   Test failed—(F8) Not all local information sources have                been Listed.            -   Attribute 7—Node Status=“2” (state 2—Under Local                Control).        -   If for any Listed local information connection (e.g., one            for which a 48—Local Information ID has become established)            its 32—Connection Status is either undefined or “1”            (connection state 1—Listed), then            -   Test failed—(F9) Not all local information connections                have become configured.            -   Attribute 7—Node Status=“2” (state 2—Under Local                Control).        -   If the Configuration Test fails to run to completion for any            other reason, then            -   Test failed—(F10) Unknown reasons.            -   Attribute 7—Node Status=“2” (state 2—Under Local                Control)        -   Otherwise,            -   Test passed—(S2).            -   If prior 7—Node Status=“2” (state 2—Under Local                Control), then Node Status=“3” (state 3—Configured).            -   Otherwise, Node Status should remain unchanged in the                prior state.

Connection Test( )—this is neither a system management command nor anevent, but it is a test of the completeness of the connections thatshould be completed between this transactive node and its connections. AConnection Test should be conducted automatically by a transactive nodeafter a successful Configure( ) command and after any connection changesits connection state. A transactive node should have passed aConfiguration Test before a Connection Test may be passed.

-   -   Parameters—None.    -   Test Logic        -   If upon checking attribute 7—Node Status this transactive            node is found to be in state “2” (2—Under Local Control),            then            -   Test failed—(F1) A transactive node should be Configured                prior to a Connection Test.            -   No further tests are required.        -   If for any 52—Transactive Neighbor ID its 32—Connection            Status is other than “3” (connection state 3—Connected) or            “4” (connection state 4—Lost Connection), then            -   Test failed—(F2) Not all transactive neighbors are                Connected.            -   Attribute 7—Node Status=“3” (state 3—Configured).        -   If for any 53—System Manager ID its 32—Connection Status is            other than “3” (connection state 3—Connected) or “4”            (connection state 4—Lost Connection), then            -   Test failed—(F3) Not all system managers are Connected.            -   Attribute 7—Node Status=“3” (state 3—Configured).        -   If for any 2—Asset ID its 32—Connection Status is other than            “3” (connection state 3—Connected) or “4” (connection state            4—Lost Connection), then            -   Test failed—(F4) Not all assets are Connected.            -   Attribute 7—Node Status=“3” (state 3—Configured).        -   If for any 26—Local Information ID its 32—Connection Status            is other than “3” (connection state 3—Connected) or “4”            (connection state 4—Lost Connection), then            -   Test failed—(F5) Not all local information connections                are Connected.            -   Attribute 7—Node Status=“3” (state 3—Configured).        -   If the Connection Test fails to run to completion for any            other reason, then            -   Test failed—(F6) Unknown reason.            -   Attribute 7—Node Status=“3” (state 3—Configured).        -   Otherwise,            -   Test passed—(S1).            -   If prior 7—Node Status=“3” (state 3—Configured), then                Node Status=“4” (state 4—Connected & Configured).            -   Otherwise, Node Status should remain unchanged in its                prior state.

Operate( ) Command

-   -   Command Parameters—None.    -   Command Logic        -   The entity making the command should be found to be this            transactive node or one of its connections. If the entity            making this system management command is not the local            system manager and does not explicitly have this command            listed among the commands in its 31—Connection Partner's            System Management Permissions, then reply            -   “Command failed—(F1) Permissions do not include this                command.”        -   If upon reviewing 7—Node Status the transactive node is            found to be in a state other than “4” (state 4—Connected &            Configured) or “5” (state 5—Operational), then reply            -   “Command failed—(F2) This command is not allowed from                current state.”        -   If upon receiving this command this transactive node is not            able to enter or remain in state 5—Operational for any            reason, then reply            -   “Command failed—(F3) Unknown reason”        -   Otherwise,            -   Reply, “Command succeeded—(S1).”            -   Set 7—Node Status=“5” (state 5—Operational).            -   Begin interacting with transactive neighbor connections                and other connections that are managed at this                transactive node according to the algorithms of the                toolkit framework and functions.

Handle Fatal Operational Event/Handle Non-Fatal Operational Event

-   -   The following error categories have been identified:        -   Application errors—an application error occurs within the            transactive control toolkit and may be due to faulty            software, logic or algorithms        -   Security and signal validation errors:—security and signal            validation errors are primarily associated with the incoming            TIS and TFS signals        -   Network errors—network errors are related to communications            network connectivity between transactive nodes.    -   Each error in these categories can further be classified as        transient (“Non-Fatal”) or permanent (“Fatal”).    -   A non-fatal error is an error where the system can recover from        the error without significant degradation of system        functionality and can therefore remain in the Operational state.        For example, if a transactive node does not receive a TIS signal        within the update interval (5 minutes for the Demonstration),        the TIS signal can be still be generated with minimal loss of        functionality (refer to the toolkit framework for how this is        accomplished). But if the TIS signal is not received for a        number of hours, then the transactive node may consider this a        fatal error and exit an Operational state. The function Handle        Non-Fatal Operational Event( ) has been provided within this        state model for the diagnostic recognition of and response to        non-fatal errors that will occur while the transactive node is        in an Operational state.    -   If a transient error happens often enough or lasts a long time        it will turn into a fatal error. Fatal errors are, by        definition, not recoverable and cause a transactive node to exit        an Operational state. One of the two categories of fatal errors        is due to a severe security, application, or network failure. A        second category occurs when a non-fatal error is repeated “N”        times in a row, or “K” times in an “M” minute interval depending        on local policies. The function Handle Fatal Operational Event(        ) has been provided within this state model for the diagnostic        recognition of and response to fatal errors that may occur while        the transactive node is in an Operational state.    -   The logic and details for these events remain to be worked out,        but at this point the logic and details should be made to work        within the state model that is being described here.

Halt Operations( ) Command

-   -   Command Parameters—None.    -   Command Logic        -   The entity making the command should be found to be this            transactive node or one of its connections. If the entity            making this system management command is not the local            system manager and does not explicitly have this command            listed among the commands in its 31—Connection Partner's            System Management Permissions, then reply            -   “Command failed—(F1) Permissions do not include this                command.”        -   If upon reviewing 7—Node Status the transactive node is            found to be in a state other than “5” (state 5—Operational),            then reply            -   “Command succeeded—(S1) Operations already halted.”        -   Otherwise,            -   Reply, “Command succeeded—(S2).”            -   Set 7—Node Status=“4” (state 4—Connected & Configured).            -   Halt interacting with transactive neighbor connections                and other connections that are managed at this                transactive node according to the algorithms of the                toolkit framework and functions.

Terminate Node( ) Command

-   -   Command Parameters—None.    -   Command Logic        -   If the entity that made this command is not the local system            manager and is not found to have been granted permission to            make this command by attribute 31—Connection Partner's            System Management Permissions, then reply            -   “Command failed—(F1) Lacking permission to make this                command”        -   If upon checking 7—Node Status, this transactive node is            found to be in a state other than “2” (state 2—Under Local            Control) or “3” (state 3—Connected), then reply            -   “Command failed—(F2) Command not accepted in present                transactive node state”        -   If the node executable fails to run for any other reason,            reply            -   “Command failed—(F3) Unknown reason”        -   Otherwise,            -   (Optional) Save a copy of the prior configuration. This                configuration may be reloaded the next time a node                executable is run to jump start the maturity of its                configuration. This is the condition of the final state                of this transactive node 1—New or Terminated.            -   Stop the node executable process from running.                Attributes may become undefined by this action.            -   Reply, “Command succeeded—(S1)”.

6.1.8 Transactive Node State Transition Table

In the table below, the numbering convention used for these functionsand events are concatenations of the prior and end states. Wheremultiple functions and events have identical prior and end states,letters have been appended. For example, “54b” is the number applied tothe second of two transitions from state number 5 to state number 4.

TABLE 9 State Transition Table for a Transactive Node Acts UponProducing Info. Internal Current Using To Set Next On the Gathered & RowFunction State Input Attributes State Output Condition Recorded 11 Failto Run 1 - New/ Filename 1 - New Reply: Failure - Command NodeTerminated parameter Terminated “Command [(F1) File log entry ExecutableSource of failed - could not be command [(F1) File found/ Attributescould not (F3) Lacking 7 - Node be found/ permission to Status and (F3)Lacking make this 31 - Connection Permission command/ Partner's to make(F4) Critical System this transactive Management command/ nodePermissions (F4) Critical attributes transactive were not nodeconfigured/ attributes (F5) were not Unknown configured/ reasons] (F5)Unknown reasons]” Command log entry 12 Run Node 1 - New/ Filename 1 -Node 2 - Under Reply: Success - Command Executable Terminated parameterID, Local “Command (S1). log entry (starting Source of 5 - Node Controlsucceeded - Node state) command Version, (S1)” executable Attributes 7 -Node Action: runs. 7 - Node Status = Node Status and “2” (stateexecutable 31 - Connection 2 - Under runs Partner's Local Command SystemControl), log entry Management and 18 - Permissions Time should beconfigured. Any and all remaining attributes may be set. 21 Terminate2 - Under Source of All 1 - New/ Reply: Success - Command Node Localcommand attributes Terminated “Command (S1) log entry Control Attributesrevert to (final succeeded - Node 7 - Node an state) (S1)” executableStatus and undefined Action: successfully 31 - state Node terminatedConnection and are executable Partner's lost when terminated System thenode Command Management executable log entry Permissions is terminated.22a Configuration 2 - Under 7 - Node 2 - Under Test log Failure - Testlog Test Local Status, Local entry [(F1) The entry Failed Control 49 -List of Control transactive Transactive node is not Neighbors,configured/ 50 - List (F2) Not all of System transactive Managers,neighbors 51 - List have been of Assets, Listed/ 38 - List (F3) Not allof Local system Information, managers 52 - have been Transactive listed/Neighbor (F4) Not all ID, 2 - assets have Asset ID, been listed/ 53 -(F5) Not all System transactive Manager neighbors ID, 48 - have becomeLocal configured/ Information (F6) Not all ID, 32 - system Connectionmanagers Status have become configured/ (F7) Not all assets have becomeconfigured/ (F8) Not all local information connections have been Listed/(F9) Not all informations have become configured/ (F10) Unknown reasons]22b Configure 2. Under Source of Node 2. Under Reply: Success - Command(Node Local command; attributes Local “Command (S1) log entryAttributes) Control Command- in the Control succeeded - line following(S1)” parameters; set may Command List of be set or log entry nodemodified attributes (e.g., that may “configured”): be {3, configured; 4,8, 9, Attributes 16, 21, 7 - Node 22, 34, Status and 38, 39, 31 -Connection 40, 41, Partner's 42, 43, System 44, 45, Management 46, 47,Permissions; 49, 50 or referenced 51} configuration file 22c Connection2 - Under 7 - Node 2 - Test log Test failed - Test log Test Failed LocalStatus, Under entry (F1) A entry Control 52 - Transactive Localtransactive Neighbor Control node should ID, be 53 - System ConfiguredManager prior to a ID, 2 - Connection Asset ID, Test 48 - LocalInformation ID, 32 - Connection Status 22d Fail to 2 - Under Source of2 - Under Reply: Failure - [(F1) Command Configure Local command; Local“Command Permissions log entry (Node Control Command- Control failed -do not Attributes) line [(F1) include this parameters; Permissionscommand/ List of do not (F3) File node include this cannot be attributescommand/ found or that may (F3) File opened/ be cannot be (F4) Incorrectconfigured; found or node ID/ Attributes opened/ (F5) Command 7 - Node(F4) Incorrect did not Status and node ID/ address 31 - Connection (F5)Command known node Partner's did not attributes/ System address (F6)Management known Unknown Permissions; node reason] Referencedattributes/ Filename. (F6) Unknown reason]” Command log entry 22e Failto 2 - Under Source of 2 - Reply: Failure - Command Operate Localcommand; Under “Command [(F1) Permissions log entry Control AttributesLocal failed - do not 7 - Node Control [(F1) Permissions include thisStatus and do command/ 31 - Connection not include (F2) This Partner'sthis command is System command/ not allowed Management (F2) This fromcurrent Permissions command state] is not allowed from current state]”Command log entry 22f Fail to Halt 2 - Under Source of 2 - Reply:Failure - (F1) Command Operations Local command, Under “CommandPermissions log entry Control Attributes Local failed - do not 7 - NodeControl (F1) include this Status and Permissions commands 31 -Connection do not Partner's include this System command” ManagementCommand Permissions log entry 22g Fail to Run 2 - Under Filename 2 -Reply: Failure - [(F1) Command Node Local parameter; Under “Command Filecould not log entry Executable Control Source Local failed - be found/of Control [(F1) File (F2) Node command; could not executable isAttributes be found/ already 7 - Node (F2) Node running] Status andexecutable 31 - Connection is already Partner's running]” System CommandManagement log entry Permissions 22h Fail to 2 - Under Source of 2 -Under Reply: Failure - [(F1) Command Terminate Local command; Local“Command Lacking log entry Node Control Attributes Control failed -permission to 7 - Node [(F1) make this Status and Lacking command/ 31 -permission (F3) Connection to make Unknown Partner's this reason] Systemcommand/ Management (F3) Permissions Unknown reason]” Command log entry22i Halt 2 - Under Source of 2 - Reply: Success - Command OperationsLocal command; Under “Command (S1) log entry Control Attributes Localsucceeded - 7 - Node Control (S1)” Status and Command 31 - Connectionlog entry Partner's System Management Permissions 23 Configuration 2 -Under Attributes 7 - Node 3 - Configured Test log Pass Test log on TestLocal 7 - Node Status = entry condition entry Passed Control Status, “3”(state (S2). See test (condition 49 - List of 3 - Configured) logic.(S2)) Transactive Transactive Neighbors, node 50 - List configuration ofSystem is complete Managers, and internally 51 - List consistent. ofAssets, 38 - List of Local Information, 52 - Transactive Neighbor ID,2 - Asset ID, 53 - System Manager ID, 48 - Local Information ID, 32 -Connection Status 31 Terminate 3 - Configured Source of All 1 - New/Reply: Success - Command Node command; attributes Terminated “Command(S1) log entry Attributes revert to (final succeeded - Node 7 - Node anstate) (S1)” executable is Status and undefined Action: terminated. 31 -Connection state Node Partner's and are executable System lost whenstops Management the node Command Permissions executable log entry isterminated. 32 Configuration 3 - Configured Attributes 7 - Node 2 -Under Test log Failure - Test log Test 7 - Node Status = Local entry[(F1) The entry Failed Status, “2” (state Control transactive 49 - Listof 2 - node is not Transactive Under configured/ Neighbors, Local (F2)Not all 50 - List Control) transactive of System neighbors Managers,have been 51 - List Listed/ of Assets, (F3) Not all 38 - List system ofLocal managers Information, have been 52 - Listed/ Transactive (F4) Notall Neighbor assets have ID, 2 - been Listed/ Asset ID, (F5) Not all53 - transactive System neighbors Manager have become ID, 48 -configured/ Local (F6) Not all Information system ID, 32 - managersConnection have become Status configured/ (F7) Not all assets havebecome configured/ (F8) Not all local information connections have beenListed/ (F9) Not all information connections have become configured/(F10) Unknown reasons] 33a Configuration 3 - Configured Attributes 3 -Configured Test log Pass Test log Test 7 - Node entry condition entryPassed Status, (S2). See test (condition 49 - List of logic. (S2)Transactive Transactive Neighbors, node 50 - List configuration ofSystem is complete Managers, and internally 51 - List consistent. ofAssets, 38 - List of Local Information, 52 - Transactive Neighbor ID,2 - Asset ID, 53 - System Manager ID, 48 - Local Information ID, 32 -Connection Status 33b Configure 3 - Configured Source of Node 3 -Configured Reply: Success - Command (Node command; attributes “Command(S1) log entry Attributes) Command- in the succeeded - line following(S1)” parameters; set may Command List of be set or log entry nodemodified attributes (e.g., that may “configured”): be {3, configured; 4,8, 9, Attributes 16, 21, 7 - Node 22, 34, Status and 38, 39, 31 -Connection 40, 41, Partner's 42, 43, System 44, 45, Management 46, 47,Permissions; 49, 50 or Referenced 51} configuration file Filename 33cConnection 3 - Configured Attributes 3 - Configured Test log Testfailed - Test log Test Failed 7 - Node entry [(F2) Not all entry Status,transactive 52 - Transactive neighbors are Neighbor Connected/ ID, (F3)Not all 53 - System system Manager managers are ID, 2 - Connected/ AssetID, (F4) Not all 48 - Local assets are Information Connected/ ID, (F5)Not all 32 - Connection local Status information connections areConnected/ (F6) Unknown reason] 33d Fail to 3 - Configured Source of 3 -Configured Reply: Failure - [(F1) Command Configure command; “CommandPermissions log entry (Node Command- failed - do not Attributes) line[(F1) include this parameters; Permissions command/ List of do not (F3)File node include this cannot be attributes command/ found or that may(F3) File opened/ be cannot be (F4) Incorrect configured; found or nodeID/ Attributes opened/ (F5) Command 7 - Node (F4) Incorrect did notStatus and node ID/ address 31 - Connection (F5) Command known nodePartner's did not attributes/ System address (F6) Management knownUnknown Permissions; node reason] referenced attributes/ configuration(F6) file Unknown reason]” Command log entry 33e Fail to 3 - ConfiguredSource of 3 - Configured Reply: Failure - Command Operate command;“Command [(F1) Permissions log entry Attributes failed - do not 7 - Node[(F1) Permissions include this Status and do command/ 31 - Connectionnot include (F2) This Partner's this command is System command/ notallowed Management (F2) This from current Permissions command state] isnot allowed from current state]” Command log entry 33f Fail to Halt 3 -Configured Source of 3 - Configured Reply: Failure - (F1) CommandOperations command, “Command Permissions log entry Attributes failed -do not 7 - Node (F1) include this Status and Permissions command 31 -Connection do not Partner's include this System command” ManagementCommand Permissions log entry 33g Fail to Run 3 - Configured Filename3 - Configured Reply: Failure - Command Node parameter; “Command [(F1))File log entry Executable Source failed - could not be of [(F1)) Filefound/(F2) command; could not Node Attributes be found/ executable is7 - Node (F2) Node already Status and executable running] 31 -Connection is already Partner's running]” System Command Management logentry Permissions 33h Fail to 3 - Configured Source of 3 - ConfiguredReply: Failure - [(F1) Command Terminate command; “Command Lacking logentry Node Attributes failed - permission to 7 - Node [(F1) make thisStatus and Lacking command/ 31 - permission (F3) Connection to makeUnknown Partner's this reason] System command/ Management (F3)Permissions Unknown reason]” Command log entry 33i Halt 3 - ConfiguredSource of 3 - Configured Reply: Success - Command Operations command;“Command (S1) log entry Attributes succeeded - 7 - Node (S1)” Status andCommand 31 - Connection log entry Partner's System ManagementPermissions 34 Connection 3 - Configured Attributes 7 - Node 4 -Connected & Test log Success - Test log Test 7 - Node Status =Configured entry (S1). entry Passed Status, “4” (state Set of 52 -Transactive 4 - connections Neighbor Connected & is complete ID,Configured) and 53 - System connected Manager ID, 2 - Asset ID, 48 -Local Information ID, 32 - Connection Status 42 Configuration 4 -Attributes 7 - Node 2 - Under Test log Failure - Test log Test Connected& 7 - Node Status = Local entry [(F1) The entry Failed ConfiguredStatus, “2” (state Control transactive 49 - List of 2 - node is notTransactive Under configured/ Neighbors, Local (F2) Not all 50 - ListControl) transactive of System neighbors Managers, have been 51 - ListListed/ of Assets, (F3) Not all 38 - List system of Local managersInformation, have been 52 - Listed/ Transactive (F4) Not all Neighborassets have ID, 2 - been Listed/ Asset ID, (F5) Not all 53 - transactiveSystem neighbors Manager have become ID, 48 - configured/ Local (F6) Notall Information system ID, 32 - managers Connection have become Statusconfigured/ (F7) Not all assets have become configured/ (F8) Not alllocal information sources have been Listed/ (F9) Not all informationsourcess have become configured/ (F10) Unknown reasons] 43 Connection4 - Connected & Attributes 7 - Node 3 - Configured Test log Testfailed - Test log Test Failed Configured 7 - Node Status = entry [(F2)Not all entry Status, “3” (state transactive 52 - Transactive 3 -Configured) neighbors are Neighbor connected/ ID, (F3) Not all 53 -System system Manager managers are ID, 2 - connected/ Asset ID, (F4) Notall 48 - Local assets are Information connected/ ID, (F5) Not all 32 -Connection local Status information sources are Connected/ (F6) Unknownreason] 44a Configuration 4 - Attributes 4 - Test log Pass Test log TestConnected & 7 - Node Connected & entry condition entry Passed ConfiguredStatus, Configured (S2). See test (condition 49 - List of logic. (S2)Transactive Transactive Neighbors, node 50 - List configuration ofSystem is complete Managers, and internally 51 - List consistent. ofAssets, 38 - List of Local Information, 52 - Transactive Neighbor ID,2 - Asset ID, 53 - System Manager ID, 48 - Local Information ID, 32 -Connection Status 44b Configure 4 - Source of Node 4 - Reply: Success -Command (Node Connected & command; attributes Connected & “Command (S1)log entry Attributes) Configured Command- in the Configured succeeded -See line following (S1)” command parameters; set may Command logic Listof be set or log entry node modified attributes (e.g., that may“configured”): be {3, configured; 4, 8, 9, Attributes 16, 21, 7 - Node22, 34, Status and 38, 39, 31 - Connection 40, 41, Partner's 42, 43,System 44, 45, Management 46, 47, Permissions; 49, 50 or Referenced 51}configuration file Filename 44c Connection 4 - Attributes 4 - Connected& Test log Success - Test log Test Connected & 7 - Node Configured entry(S1) entry Passed Configured Status, All 52 - Transactive connectionsNeighbor are complete ID, and 53 - System connected. Manager ID, 2 -Asset ID, 48 - Local Information ID, 32 - Connection Status 44d Fail to4 - Connected & Source of 4 - Connected & Reply: Failure - [(F1) CommandConfigure Configured command; Configured “Command Permissions log entry(Node Command- failed - do not Attributes) line [(F1) include thisparameters; Permissions command/ List of do not (F3) File node includethis cannot be attributes command/ found or that may (F3) File opened/be cannot be (F4) Incorrect configured; found or node ID/ Attributesopened/ (F5) Command 7 - Node (F4) Incorrect did not Status and node ID/address 31 - Connection (F5) Command known node Partner's did notattributes/ System address (F6) Management known Unknown Permissions;node reason] referenced attributes/ configuration (F6) file Unknownreason]” Command log entry 44e Fail to 4 - Connected & Source of 4 -Connected & Reply: Failure - Command Operate Configured command;Configured “Command [(F1) Permissions log entry Attributes failed - donot 7 - Node [(F1) Permissions include this Status and do command/ 31 -Connection not include (F3) Unknown Partner's this reason] Systemcommand/ Management (F3) Unknown Permissions reason]” Command log entry44f Fail to Halt 4 - Connected & Source of 4 - Connected & Reply:Failure - (F1) Command Operations Configured command, Configured“Command Permissions log entry Attributes failed - do not 7 - Node (F1)include this Status and Permissions command 31 - Connection do notPartner's include this System command.” Management Command Permissionslog entry 44g Fail to Run 4 - Filename 4 - Reply: Failure - [(F1)Command Node Connected & parameter; Connected & “Command File could notlog entry Executable Configured Source Configured failed - be found/ of[(F1) File (F2) Node command; could not executable is Attributes befound/ already 7 - Node (F2) Node running] Status and executable 31 -Connection is already Partner's running]” System Command Management logentry Permissions 44h Fail to 4 - Source of 4 - Reply: Failure - [(F1)Command Terminate Connected & command; Connected & “Command Lacking logentry Node Configured Attributes Configured failed - permission to 7 -Node [(F1) make this Status and Lacking command/ 31 - permission (F2)Connection to make Command Partner's this not accepted System command/in present Management (F2) transactive Permissions Command node state]”not accepted in present transactive node state]” Command log entry 44iHalt 4 - Source of 4 - Reply: Success - Command Operations Connected &command, Connected & “Command (S1) log entry Configured AttributesConfigured succeeded - 7 - Node (S1)” Status and Command 31 - Connectionlog entry Partner's System Management Permissions 45 Operate 4 -Connected & Source of 7 - Node 5 - Operational Reply: Success - CommandConfigured command; Status = “Command (S1) log entry Attributes “5”(state succeeded - 7 - Node 5 - (S1)” Status and Operational) Action:31 - Connection Transactive Partner's node System begins Managementinteracting Permissions with transactive control and coordination systemCommand log entry 53 Connection 5 - Operational Attributes 7 - Node 3 -Configured Test log Test failed - Test log Test Failed 7 - Node Status =entry [(F2) Not all entry Status, “3” (state transactive 52 -Transactive 3 - Configured) neighbors are Neighbor Connected/ ID, (F3)Not all 53 - System system Manager managers are ID, 2 - Connected/ AssetID, (F4) Not all 48 - Local assets are Information Connected/ ID, (F5)Not all 32 - Connection local Status information sources are Connected/(F6) Unknown reason] 54a Handle 5 - Operational Diagnostic 7 - Node 4 -Connected & Notifications Non- Event log Fatal recognition Status =Configured TBD recoverable entry Operational of Fatal “4” (state Eventlog error during Event Operational 4 - entry transactive Event Connected& node Details Configured) operations TBD 54b Halt 5 - OperationalSource of 7 - Node 4 - Connected & Reply: Success - Command Operationscommand; Status = Configured “Command (S2) log entry Attributes “4”(state succeeded - 7 - Node 4 - (S2)” Status and Connected & Action: The31 - Connection Configured) transactive Partner's node halts System itsManagement interactions Permissions with the transactive control andcoordination system Command log entry 55a Configuration 5 - OperationalAttributes 5 - Operational Test log Pass Test log Test 7 - Node entrycondition entry Passed Status, (S1). See test (condition 49 - List oflogic. (S1) Transactive Transactive Neighbors, node 50 - Listconfiguration of System is complete Managers, and internally 51 - Listconsistent of Assets, 38 - List of Local Information, 52 - TransactiveNeighbor ID, 2 - Asset ID, 53 - System Manager ID, 48 - LocalInformation ID, 32 - Connection Status 55b Connection 5 - OperationalAttributes 5 - Operational Test log Success - Test log Test 7 - Nodeentry (S1) entry Passed Status, All 52 - Transactive connectionsNeighbor are complete ID, and 53 - System connected. Manager ID, 2 -Asset ID, 48 - Local Information ID, 32 - Connection Status 55c Fail to5 - Operational Source of 5 - Operational Reply: Failure - [(F1) CommandConfigure command; “Command Permissions log entry (Node Command-failed - do not Attributes) line [(F1) include this parameters;Permissions command/ List of do not (F2) Configure node include thiscommand attributes command/ not allowed that may (F2) Configure from becommand Operational configured; not allowed state] Attributes from 7 -Node Operational Status and state]” 31 - Connection Command Partner'slog entry System Management Permissions; Referenced configuration fileFilename 55d Fail to Halt 5 - Operational Source of 5 - OperationalReply: Failure - (F1) Command Operations command, “Command Permissionslog entry Attributes failed - do not 7 - Node (F1) include this Statusand Permissions command 31 - Connection do not Partner's include thisSystem command” Management Command Permissions log entry 55e Fail to Run5 - Operational Filename 5 - Operational Reply: Failure - [(F1) CommandNode parameter; “Command File could not log entry Executable Sourcefailed - be found/ of [(F1) File (F2) Node command; could not executableis Attributes be found/ already 7 - Node (F2) Node running] Status andexecutable 31 - Connection is already Partner's running]” System CommandManagement log entry Permissions 55f Fail to 5 - Operational Source of5 - Operational Reply: Failure - [(F1) Command Terminate command;“Command Lacking log entry Node Attributes failed - permission to 7 -Node [(F1) make this Status and Lacking command/ 31 - permission (F2]Connection to make Command Partner's this not accepted System command/in present Management (F2] transactive Permissions Command node state]not accepted in present transactive node state]” Command log entry 55hOperate 5 - Operational Source of 5 - Operational Reply: Success -Command command; “Command (S1) log entry Attributes succeeded - 7 - Node(S1)” Status and Command 31 - Connection log entry Partner's SystemManagement Permissions

6.1.9 Connection Attributes

Connection attributes have been identified and are ascribable in commonto the four types of connections. This set of attributes refers to asingle connection between this transactive node and a transactiveneighbor, system manager, asset system, or source of local information.The connection attributes are indispensible for keeping track of thestate of any type of connection. It is never adequate to reference theseattributes apart from a specific example of attribute 27—Connection ID.

Connection attributes are important for navigating the connection statetransition diagram 3000 in FIG. 30. The attribute 32—Connection Statusshould be known and managed for each connection. Attribute 7—Node Statushas been shown to be a logical combination of multiple individualConnection Statuses.

Refer to Table 11 for the anticipated ways in which the connectionattributes may be affected by the commands and events of the connectionstate model.

In the connection state model (see FIG. 30), a connection moves betweenits states by undergoing Configuration Tests, accepting Connect andDisconnect commands, and experiencing some events like Loss ofConnection. Important connection attribute 32—Connection Status keepstrack of these state changes. For example, a local informationconnection transitions into state Connection Status “2” (connectionstate 2—Configured) if connection attribute 32—Connection Status and thelocal information attribute 48—Connection Status have been configured.(The sets of attributes that should be configured before a connectionmay enter connection state 2—Configured are indicated conveniently byasterisks in FIG. 28.)

TABLE 10 Dictionary of Connection Attributes that should be applied toeach Connection Attribute No. Name Description Role Type Format Range ofvalues 32 Connection Indicates the Affected by Integer Example: “2” 1 -Listed, Status* state of the Connect( ) 2 - Configured, connectioncommand. 3 - Connected, between this A transactive 4 - Lost transactivenode Connection node and a conducts a connection. Connection Test basedon the Connection Statuses of its connections. 29 Connection Anindicator May be used Character Example: “RL”—Responsive Partner of typeof to indicate string “SM” Load Type* connection applicable partner frominteractions “OL”—Other a list of and Local allowed permissions.Condition partner types For example, Input to include at transactive“OS”—Owner least neighbors or transactive expect to Subsystem neighbors,receive and “RR”—Responsive owner. supply Rsource transactive signals.“SM”—System System Manager managers “TN”—Transactive should be Neighborgranted some system management permissions. 17 Connection Optional EachList of Detail1, A list of Details additional connection alphanumericdetail2, . . . necessary details about method used is strings detailsshould the in attribute be created for connection 33 - Connection eachmethod on Method connection stated in should method of attributeprescribe a attribute 33. For 33 - Connection set of details example, onMethod that should Internet (IP for a be provided address of thisconnection. by this transactive attribute. node, IP address ofconnection partner, encryption level, . . . ) 28 Connection's Thelocations Support Most likely (latitude, 0-360 Geographical ofconnection future GIS a pair of longitude) As degrees; Location partnerssystem real for attribute 0-2 * pi radians should be representationsnumbers #4. provided to representing Geographical identify map angularLocation, locations to latitude and angular which this longitude.latitude and transactive longitude are node has the default establishedunits. connections. Standard This attribute GIS is optional forrepresentation each formats connection. should be adapted if suchstandards can be identified. 30 Entities For each Eventually, List ofUse If null, only the Permitted specified the alphanumeric guidancelocal transactive to Modify connection, a transactive identifiers,provided with node system this list of those nodes will one for 1 - NodeID manager may Connection entities that operate with each entity andmodify the are permitted considerable that will be 28 - Connectionspecified to initiate, autonomy granted this ID. Use connection. modify,or and should permission formats disconnect clearly for this found inthe specify connection. transactive connection which, if any control andand its connection coordination attributes. partners may system Thislist may modify topology narrow the connections. maps. permissions Thegranted to a Demonstration connection has many partner by instancesattribute where a utility 31 - Connection owner should Partner begranted Permissions. permissions to modify a transactive node'sconnections. 31 Connection The general This attribute List of List ofEntries selected Partner's permissions allows system allowed from Systemgranted to system management system {Configure([All, Managementconnection management commands management 1, 2, . . . ]), Permissionspartners to responsibilities that will be commands Connect, issue systemto be accepted {command1, Disconnect, management assigned to from acommand2, Operate, Run commands at one or more connection . . . }. Ifthe list Node this of the partner at includes Executable, transactiveconnection this command Stop, Terminate node, plus partners attransactive Configure( ), Node} the this node, plus the list of If null,then only transactive transactive list of modifiable this transactivenode node. transactive attributes node's system attributes Assigned nodeshould be manager may that may be among attributes listed as issuesystem modified by Connection that may be parameters management theTable modified by of this commands. connection attributes. this commandby partner See connection number. during Connection partner.configuration. Table. These permissions may be restricted further byattribute 30 - Entities Permitted to Modify this Connection. 33Connection Optional Specify the Single Example: Ethernet, Methodindication of method of character “Internet” Internet, the mediaconnection. string Wireless and protocol Each such Zigbee ®, used in amethod may Wireless other, connection. then have Power Line specificCarrier details to be listed in attribute 34 - Connection Details. 54Connection The period of This is the Character Recommend The Timeouttime that a amount of string “dd:hh:mm”. Demonstration Period given timethat representation Should should use connection should of a emulate UTCvalues longer will remain in elapse before single time standard than 5minutes its Lost a connection duration format that is “00:00:05” orConnection in its Lost used shorter than 4 state before Connectionfrequently in days “04:00:00”. it will state will state model. Defaultvalue: 1 terminate the automatically hour: connection, transition“00:01:00”. which could back into its threaten the ConfiguredOperational state. This status of this duration may transactive be quitelong node. if this transactive node and its algorithms have beendesigned tolerant of poor connectivity. This timeout period is to beindividually configured for each connection. 55 Loss of A list of timesBy keeping List of UTC See UTC Allow for cyclic Connection at whichtrack of when times. standard buffer of 64 on Event Loss of Loss ofvalues. Buffer Connection Connection Need not be Events have Eventsoccur, initialized. occurred for a transactive a given node canconnection. take exceptional actions based on the frequency with whichthe events have occurred. 56 Allowed The Criteria Two Example: (5,Default (6, 48), Frequency frequency placed on the integers. 24),meaning meaning six of Loss with which members of 5 times in an times inan of Loss of 55 - Loss of hour, or 24 hour, or 48 Connection ConnectionConnection times in a times in during Events Events will Event Buffer.day a day. Integers be tolerated The should be less before theconnection than the buffer connection should be length of will besevered if 55 - Loss of severed. these Connection There is a frequenciesEvent Buffer. criterion for are events per exceeded, hour and whichwould another for indicate a events per problem with day. theconnection.

TABLE 11 The Ways Connection Attributes May be Affected by ConnectionState Model Commands and Events Loss of Re-Establish Terminate ConfigureConfiguration Connect Disconnect Connection Connection ConnectionAttribute # Attribute Name Command Test** Command Command Event EventEvent 32 Connection Status* +0 C + 0 C0 C0 C00 C00 C00 29 ConnectionPartner Type* +0 C (C) 30 Entities Permitted to C + 0 C Modify thisConnection 31 Connection Partner's C + 0 C C System ManagementPermissions 17 Connection Details +0 (C) (C) (C) (C) 28 Connection'sGeographical +0 Location 33 Connection Method +0 (C) (C) (C) (C) (C) 54Connection Timeout Period +0 C C C 55 Loss of Connection +0 C + 0 EventBuffer 56 Allowed Frequency of +0 C Loss of Connection Events *TheConnection Status should be configured before a connection can enter its2 - Configured state. **The connection Configuration Test additionallyshould check one or more attributes of the connection partner type.

6.1.10 Transactive Neighbor Connection Attributes

In certain embodiments, transactive node define at least one connectionto a transactive neighbor. The connection may be observed and maintainedusing the union of connection attributes and transactive node attributes(see FIG. 28).

At least for some of the connections that are being made to transactiveneighbors, it may be desired that experimenters and testing entitieshave the means to redirect the inputs received from the transactiveneighbors so that these inputs may be received instead from selectedalternative sources of such information. It is likewise important thatone may redirect the output from these connection partners to one ormore alternative locations. For the special type of connection partnerscalled transactive neighbors, the means to redirect inputs and outputshas been accomplished with attributes 10-13, which attributes define thesources and targets of transactive signals. The sources and targets arenot necessarily the transactive neighbor itself. Using these attributes,simulations and “what-if” scenarios may be designed and tested in theproduction or test system environments. (So far, attributes #10-13 onlyapply to transactive neighbors and their connections. It is conceivablethat the attributes could be generalized and renamed to apply to anyconnection type, not only transactive neighbors.)

TABLE 12 Dictionary of Transactive Neighbor Attributes Attribute No.Name Description Role Type Format Range of values 52 Transactive TheThis asset Single character Example #1: See system Neighbor identifierto should be string “UT06”, which is the topology. ID* be used forrepeated for Demonstration's Naming practice one each identifier for theshould be the transactive member of Avista utility. same here and forneighbor 49 - List of attribute 49 - List with which Transactive ofTransactive this Neighbors Neighbors. transactive to node willinstantiate exchange the electrical transactive energy and neighborstherefore that this will transactive exchange node transactive expectsto signals. interact with. This transactive neighbor enters its Listedstate after this attribute has been configured. 10 Receive TIS The ThisSingle, short Use guidance Source should be Source* Connection attributealphanumeric provided with a known source ID of a permits identifier foreach 1 - Node ID and within present source from alternative transactive28 - Connection ID. transactive control which a TIS neighbor. Useformats found and coordination transactive examples to in transactivesystem. neighbor's be received control and TIS should at thiscoordination system be transactive topology maps. received. node fromThe source alternative is not sources to necessarily facilitate thetesting and transactive simulation. neighbor itself. 11 Receive The ThisSingle, short Use guidance Source should be TFS Connection attributealphanumeric provided with a known source Source* ID of a permitsidentifier for each 1 - Node ID and within present source fromalternative transactive 28 - Connection ID. transactive control which aTFS neighbor Use formats found and coordination transactive examples toin transactive system. neighbor's be received control and TFS should atthis coordination system be transactive topology maps. received. node toThe source facilitate is not the testing and transactive simulation.neighbor itself. 12 Send TIS The This List of one or Use guidance Targetshould be Targets* Connection attribute many single provided with knownlocation ID of at permits this short 1 - Node ID and within presentleast one transactive alphanumeric 28 - Connection ID. transactivecontrol target node's TIS identifiers for Use formats found andcoordination location to to be sent to each transactive in transactivesystem. which this one or more neighbor control and transactive placesto coordination system node's TIS facilitate topology maps. should betesting and sent. The simulation. target location is not necessarilythat of the transactive neighbor itself. 13 Send TFS The This List ofone or Use guidance Target should be Targets* Connection attribute manysingle provided with known location ID of at permits this short 1 - NodeID and within present least one transactive alphanumeric 28 - ConnectionID. transactive control target node's TFS identifiers for Use formatsfound and coordination location to for this each transactive intransactive system. which this transactive neighbor control andtransactive neighbor to coordination system node's be sent to topologymaps. calculated one or more TFS with places to this facilitatetransactive testing and neighbor simulation. should be sent. The targetlocation is not necessarily that of the transactive neighbor itself. 23Received Contains at Each List of TIS According to See range TIS Bufferleast the transactive transactive signal attributes of TIS most recentneighbor's format as defined TIS TIS is used by approved XML messageswithin the schema for the TIS. received toolkit from each frameworktransactive algorithms. neighbor. To be stored to the Input TransactiveSignal Buffer of the toolkit framework. 24 Received Contains at EachList of TFS According to See range TFS Buffer least the transactivetransactive signal attributes of the most recent neighbor's format asdefined TFS TFS TFS is used by approved XML messages within the schemafor the received toolkit TFS. from each framework transactivealgorithms. neighbor. To be stored to the Input Transactive SignalBuffer of the toolkit framework. 59 TIS Sent Flag that is This flagBoolean Boolean logic. 0 - default value - Flag set if a TIS may becondition flag: cleared - no TIS has been used in 0 - cleared has beentransmitted conjunction 1 - set transmitted to this to this with thetransactive transactive watchdog neighbor yet neighbor timer. The duringthe current connection actions update interval. by this taken upon 1 -set - a TIS transactive a watchdog has been node during timer eventtransmitted to this the current may transactive update desirablyneighbor during interval. have the the current update The flag istransactive interval. cleared at node keep the track of to beginningwhich of each transactive update neighbor interval. transactive signalshave been transmitted and not. 60 TFS Sent Flag that is This flagBoolean Boolean logic. 0 - default value - Flag set if a TFS may becondition flag: cleared - no has been used in set/cleared. TFS has beentransmitted conjunction transmitted to this to this with the transactivetransactive watchdog neighbor yet neighbor by timer. The during thecurrent this actions update interval. transactive taken upon 1 - set - aTFS node during a watchdog has been the current timer event transmittedto this update may transactive interval. desirably neighbor during Theflag is have the the current update cleared at transactive interval. thenode keep beginning track of to of each which update transactiveinterval. neighbor transactive signals have been transmitted and not.*This attributes should be configured to pass a connection ConfigurationTest.

TABLE 13 The Ways Transactive Neighbor Attributes May be Affected byConnection State Model Commands and Events Loss of Re-EstablishTerminate Configure Configuration Connect Disconnect ConnectionConnection Connection Attribute # Attribute Name Command Test** CommandCommand Event Event Event 52 Transactive Neighbor (C) + 0 C (C) (C) (C)(C) (C) ID* 10 Receive TIS Source* +0 C (C) (C) (C) (C) (C) 11 ReceiveTFS Source* +0 C (C) C) (C) (C) (C) 12 Sent TIS Targets* +0 C (C) (C)(C) (C) (C) 13 Send TFS Targets* +0 C (C) (C) (C) (C) (C) 23 ReceivedTIS Buffer +0 24 Received TFS Buffer +0 *These attributes should beconfigured before a transactive neighbor connection can enter its 2 -Configured state. **The connection Configuration Test additionallyshould check that 32 - Connection Status has been configured.

6.1.11 System Manager Connection Attributes

In certain embodiments, a single attribute can define a connection to asystem manager.

TABLE 14 Ways in which System Manager Connection Attributes may beaffected by Connection Commands and Events Loss of Re-EstablishTerminate Configure Configuration Connect Disconnect ConnectionConnection Connection Attribute # Attribute Name Command Test** CommandCommand Event Event Event 52 System Manager (C) + 0 C (C) (C) (C) (C)(C) ID* *The Connection Status should be configured before a connectioncan enter its 2 - Configured state. **The connection Configuration Testadditionally should check one or more attributes of the connectionpartner type.

Note that in certain implementations, transactive nodes establish andmaintain a connection to the global system manager. Therefore, attribute52 System Manager ID includes the ID of this global system manager forthe transactive nodes.

TABLE 15 Dictionary of System Manager Connection Attributes AttributeRange of No. Name Description Role Type Format values 52 System Theidentifier This attribute Single Example #1: See system Manager for onesystem instantiates a character “EI01” to topology. ID* manager. Thissystem manager strings represent the Naming entity will be from thosethat system practice granted appear in 50 - List manager, from should bepermissions by of System which system the same this transactiveManagers. A system management here and for node to make manager forwhich command will attribute some system this attribute has likely be50 - List of management been configured will received. System commands.enter its Listed state. Managers. A system manager is not a transactiveneighbor, but a transactive neighbor may be granted permissions to actas a system manager. This transactive node may instantiate multipleconnections to system managers. The Demonstration, for example, willhave some central system management (“EI01”), but this transactive nodemay also grant system administration rights to the utility that “owns”this transactive node.

6.1.12 Asset Connection Attributes

This group of Asset attributes are meaningful only in respect to a givenconnection to an asset, which can be an energy resource, an incentive,or a load. Each resource or incentive has a corresponding toolkitresource and incentive function that defines how its behavior andeffects may be modeled or predicted for the formulation of thetransactive signals according to the toolkit framework. Each loadsimilarly should have a corresponding toolkit load function thatdescribes its effect on the formulation of the TFS. Often these “assets”will, in fact, be rather complex systems of assets.

An asset connection may list a set of local information connections thatshould be established via its 38—List of Local Information. Each memberof this list creates an expectation that a local information connectionwill become established.

An asset connection should have its 2—Asset ID, 6—Toolkit Function, and6—Asset Type configured before it is able to enter into the connectionstate 2—Configured

TABLE 16 Dictionary of Asset Connection Attributes Attribute Range ofNo. Name Description Role Type Format values 2 Asset ID* This attributeEach Character Recommend The identifies the resource, string format “XX-Demonstration resources, incentive, or #” for each has alreadyincentives, load should be asset, where specified and loads identified“XX” is a 2- identifiers for associated along with its letter responsivewith this toolkit acronym for asset systems transactive function, theowner of (most of which control node. status, this are loads) predicted/transactive according to scheduled node, and “#’ this engagement, is aninteger convention. etc. number that Loads = [0-999] ensures thatResources = the identifier [1000-1999] is unique. Incentives =[2000-2999] 6 Toolkit An States the List of {filename1, Valid Functionidentification specific toolkit Alphanumeric #.##; filenames are ID* ofthe function and modules or filename2, to be used. specific version thatis filenames and #.##, . . . } “#.##” is major toolkit being applied thepresent and minor function and at this version of version version-thetransactive these numbers using functional node for each modules. digits0-9. algorithms resource, used at this incentive, or transactive load.node to A toolkit process the function TIS, TFS, should be local namedfor information, each and to resource, control incentive, and associatedload for which assets. predictive behavior is being modeled by a toolkitfunction. 25 Asset Enables a This feature List of See 2 - Should referto Output control may facilitate alphanumeric Asset ID. valid resourceTargets* output to a using the identifiers or load entity resource orinstalled ID from the load to transactive 2 - Asset IDs become controland that are being redirected to coordination used. one or more systemfor target simulation of locations. asset The target responses locationsdo under not alternative necessarily scenarios and include the duringtesting. resource or If targets do load itself. not include the assetsystem, the asset should not respond. Should be configured for asuccessful connection Configuration Test. 36 Asset Type Declaration Maybe useful Single Example: “Resource”—describes of asset type foralphanumeric “Resource” a at least from categorization string generatoramong of asset resource at “Resource,” connections. this transactive“Incentive,” Range of node. and “Load.” values may be“Incentive”—describes expanded. an See the toolkit incentive thatframework to is not a understand resource. the roles of “Load”—describestoolkit an functions. elastic or inelastic load at this transactivenode. 38 List of Local A list of the An asset's List of See 48 - ShouldInformation sources of predicted character Local correspond toConnections local behavior is strings Information valid 48 - informationmodeled by a ID. Local that will be toolkit Information ID. called uponfunction, to help which in turn predict the may call upon behavior ofsources of this asset. local information. A connection listed in thisattribute creates an expectation that this transactive node willestablish and manage the connection.

To support future simulations and testing, the connection state modelincludes an ability to redirect the output of these asset connections.Some of the assets will be responsive to the transactive control andcoordination system and an output “control” signal is sent to theseasset systems by this transactive node. Attribute 25—Asset OutputTargets allows the targets of these “control” signals to be sent to theasset system, to another entity, or to both the asset system the otherentity.

List the local information inputs that are anticipated by an assetsystem and the toolkit function that predicts its behaviors. Thesestreams of input information that are at time referred to as “otherlocal conditions” should additionally become listed as attributes48—Local Information ID so that the continuity of the data stream may bemonitored and so the input can become redirected, thus allowingalternative scenarios to be simulated with alternative inputinformation.

Table 17 lists the asset attributes and indicates how these attributesmay be affected by the system management commands and events that arepart of the connection state model.

TABLE 17 The Ways Asset Attributes May be Affected by Connection StateModel Commands and Events Loss of Re-Establish Terminate ConfigureConfiguration Connect Disconnect Connection Connection ConnectionAttribute # Attribute Name Command Test** Command Command Event EventEvent 2 Asset ID* C + 0 C (C) (C) (C) (C) (C) 6 Toolkit Function* +0 C25 Asset Output Targets* (C) + 0 C (C) (C) (C) (C) (C) 36 Asset Type +0(C) 38 List of Local Information (C) + 0 C (C) (C) (C) (C) (C)Connections *These attributes should be configured before an assetconnection can enter its 2 - Configured state. **The connectionConfiguration Test additionally should check that 32 - Connection Statushas been configured.

The Assets in the Asset Table of Table 16 are closely aligned withseveral of the interim data storage areas (“buffers”) that have beendefined in the toolkit framework and with appear also in the state mode.For an asset connection there should be corresponding entries in one ormore of the buffer (storage) areas that have been defined in the toolkitframework:

-   -   Resource entries necessitate updating one record in attribute        34—Resource Schedule and Cost Buffer during each iteration at        the update frequency. (An exception may occur because an option        has been provided for resource schedules to be entered without        corresponding toolkit functions. This might be selected for some        resources that are dispatched entirely unaffected by transactive        control.) For a resource, this entry will state at least an        energy parameter and average power produced by the corresponding        resource for each interval start time.    -   Incentive entries, like resources, also necessitate updating one        record in attribute 34—Resource Schedule and Cost Buffer during        each iteration at the update frequency. That entry will include        entries from among a paired set of capacity factor and capacity,        an infrastructure parameter, and another costs parameter.    -   Load entries necessitate one record be made in each attribute        45—Inelastic Load Prediction Buffer and 46—Elastic Load        Prediction Buffer each iteration. The entries in those buffer        (storage) locations predict load and, for responsive assets, the        predicted level of engagement of responsive asset systems.

6.1.13 Local Information Connection Attributes

TABLE 18 Dictionary of Local Information Connection Attributes AttributeRange of No. Name Description Role Type Format values 48 Local UniqueThis ID should Single Recommend “XX- Should match Information identifierto be listed in a character OLC-3###”, formats and ID* keep track ofrecord of the string. where XX is an entries in the local Connectionsacronym for the 38 - List of information Table. node owner, Local thatare used Once clearly “3###” is a Information by this identified, thisnumber from Connections transactive input may 3000 to 3999. node. thenbe Example: “AV- “Local supplied by OLC-3001” Information” alternativehas been sources via referred to as the attribute “Other Local 26 -Local Conditions” in Information the toolkit Source. framework and inother sections. 26 Local One source of Enables an Character Example 1:Alternative 1: Information Local alternative string. “AV3015” ID ofother Source* Information source of Example 2: “EI01” local willnormally other local Example 3: condition be the actual conditions to“OLCFile01.exe” provider from source of the be used to Other Local data.This facilitate Condition attribute testing and Table. allows that thesimulation. Alternative 2: input data may Valid ID from be receivedamong from Connection alternative Table records sources. Alternative 3:Valid filename in known directory.

A transactive node may possess many assets, and each asset may invokemultiple input information streams. Therefore, the local informationconnections should be carefully defined in the connection state model,and two attributes have been grouped as local information connectionattributes.

A local information connection is an input that is invoked by and usedby a toolkit function. Experimenters and testing personnel may wish tointentionally insert other alternative input information into thetoolkit functions via this local information to simulate alternativescenarios that would be unlikely to occur under normal operations.Attribute 48 has been provided for this purpose, with which the sourceof the local information may be received from either the normalinformation provider or from an alternative source like an input file.

Table 19 lists which of the state model's commands and events areexpected to modify the two Other Local Condition Attributes.

TABLE 19 Ways in Which Local Information Connection Attributes May beAffected by Commands and Events in this State Model Loss of Re-EstablishTerminate Configure Configuration Connect Disconnect ConnectionConnection Connection Attribute # Attribute Name Command Test** CommandCommand Event Event Event 48 Local Information ID* C + 0 C (C) (C) (C)(C) (C) 26 Local Information +0 C (C) (C) (C) (C) (C) Source* *Theseattributes should be configured before a local information connectioncan enter its 2 - Configured state. **The connection Configuration Testadditionally should check that 32 - Connection Status has beenconfigured.

6.1.14 Functions and Events of the Connection State Model

Configure( ) (Connection Attributes) Command—the same flexible commandthat was applied to the transactive node may also be used forconfiguring the connections that a transactive node manages. Only thenew parameters that should be used for connections will be presented;most parameters that were used for the transactive node state model willnot be repeated. This command is used with connection attributes byfirst referring to the respective connection identifier (e.g., contentsof attributes 52, 2, 53, or 48) and setting or modifying thatconnection's remaining attributes.

-   -   Command Parameters        -   ConfigureFile=(Filename)—If a file is named using this            parameter, a command script will be read from Filename found            in a known file directory. It is recommended that the            Filename should contain scripted parameters as would be used            an in-line command.        -   Any combination of the following comma-separated, in-line            command parameters may be used and in any order:        -   TransactiveNeighbor=(52—Transactive Neighbor ID)—If the            Transactive Neighbor ID does not match an existing one,            configure a new Transactive NeighborID. The commands that            follow this command in the sequence of command parameters            are assumed to refer to this transactive neighbor            connection. This command parameter may be used again to            reference another transactive neighbor connection.        -   TransactiveNeighborDelete—Remove the record for the most            recently referenced Transactive Neighbor ID.        -   TransactiveNeighborAttribute=attribute #, attribute value            1[[, attribute value 2], . . . ]—This parameter may be used            to initialize or change the contents of any transactive            neighbor connection attribute except attributes            52—Transactive Neighbor ID and 32—Connection Status.    -   SystemManager=(53—System Manager ID)—If the System Manager ID        does not match an existing one, configure a new System Manager        ID. The commands that follow this command in the sequence of        command parameters are assumed to refer to this system manager        connection. This command parameter may be used again to        reference another system manager connection.        -   SystemManagerDelete—Remove the record for the most recently            referenced System Manager ID.        -   SystemManagerAttribute=attribute #, attribute value 1[[,            attribute value 2], . . . ]—This parameter may be used to            initialize or change the contents of any system manager            connection attribute except attributes 53—System Manager ID            and 32—Connection Status.        -   Asset=(2—Asset ID)—If the Asset ID does not match an            existing one, configure a new Asset ID. the commands that            follow this command in the sequence of command parameters            are assumed to refer to this asset connection. This command            parameter may be used again to reference another asset            connection.            -   AssetDelete—Remove the record for the most recently                referenced Asset ID.            -   AssetAttribute=attribute #, attribute value 1[[,                attribute value 2], . . . ]—This parameter may be used                to initialize or change the contents of any asset                connection attribute except attributes 2—Asset ID and                32—Connection Status.        -   LocalInformation=(48—Local Information ID)—If the Local            Information ID does not match an existing one, configure a            new Local Information ID. The commands that follow this            command in the sequence of command parameters are assumed to            refer to this local information connection. This command            parameter may be used again to reference another local            information connection.            -   LocalInformationDelete—Remove the record for the most                recently referenced Local Information ID.            -   LocalInformationAttribute=attribute #, attribute value 1                [[, attribute value 2], . . . ]—This parameter may be                used to initialize or change the contents of any local                information connection attribute except attributes                48—Local Information ID and 32—Connection Status.    -   Command Logic        -   If the entity that made this command is not the local system            manager and if the entity has not been explicitly given            permission to make this system management command among the            commands in its 31—Connection Partner's System Management            Permissions, then reply            -   “Command failed—(F1) Permissions do not include this                command”        -   From transactive node part of state model, which addressed            the Configure function, if attribute 7—Node Status=“5”            (state 5—Operational), then reply            -   “Command failed—(F2) Configure command not allowed from                Operational state.”        -   If 32—Connection Status is “3” (connection state            3—Connected) or “4” (connection state 4—Lost Connection),            from which configuration of a connection is not be            permitted, then reply            -   “Command failed—(F12) Configure command not allowed from                connected connection states.”        -   If Filename cannot be found, reply            -   “Command failed—(F3) File cannot be found or opened”        -   Failure conditions F4 (Incorrect node ID) and F5 (Command            did not address known node attributes) do not apply during            configuration of connections but should be reserved            nonetheless.        -   If the entity making this system management command attempts            to change a given connection's attributes, but the entity is            not listed among this connection's 30—Entities Permitted to            Modify this Connection (applies to any of the types of            connections), then reply            -   “Command failed—(F7) Entity making command does not have                permission to configure this connection.”        -   If the transactive neighbor connection attribute number does            not match a known transactive neighbor connection attribute            number (e.g., is not a member of {10, 11, 12, 13, 17, 23,            24, 28, 29, 30, 31, 33}), or if no 52—Transactive Neighbor            ID has been stated as a parameter before this command            attempts to configure its attributes, then reply            -   “Command failed—(F8) Command did not address known                transactive neighbor connection attributes”        -   If the system manager connection attribute number does not            match a known system manager connection attribute number            (e.g., is not a member of {17, 28, 29, 30, 31, and 33}), or            if no 53—System Manager ID has been stated as a parameter            before this command attempts to configure its attributes,            then reply            -   “Command failed—(F9) Command did not address known                system manager connection attributes”        -   If the asset connection attribute number does not match a            known asset connection attribute number (e.g., is not a            member of {6, 17, 25, 28, 29, 30, 31, 33, 36, and 38}), or            if no 2—Asset ID has been stated as a parameter before this            command attempts to configure its attributes, then reply            -   “Command failed—(F10) Command did not address known                asset connection attributes”        -   If the local information connection attribute number does            not match a known local information connection attribute            number (e.g., is not a member of {17, 26, 28, 29, 30, 31,            and 33}), or if no 48—Local Information ID has been stated            as a parameter before a command attempts to configure its            attributes, then reply            -   “Command failed—(F11) Command did not address known                local information connection attributes”        -   If the command cannot be completed for any other reason,            reply            -   “Command failed—(F6) Unknown reason”        -   Otherwise,            -   Reply, “Command succeeded—(S1)”            -   Finalize any changes to connection attributes that were                specified in the file or in-line command.            -   Run a Connection Configuration Test on this connection.            -   Run a transactive node Configuration Test on this                transactive node.

Connection Configuration Test( )—a simple test of a given connection'sattributes to determine if the connection may transition into or remainin its 2—Configured state. A connection in either its 3—Connected or4—Lost Connection state has, by definition passed its ConnectionConfiguration Test. If a connection passes its Connection ConfigurationTest, it should be in state 2—Configured; if it fails, it should be instate 1—Listed.

A Connection Configuration Test is not a system command. It should beinitiated by the logic of the transactive node and by the transactivenode itself. It should be run for a given connection anytime that theConfigure( ) command has run successfully and might have thereforemodified the configuration of the connection.

-   -   Test Parameters        -   All=test each connection according to its connection type        -   TransactiveNeighbor=(52—Transactive NeighborID)—conduct the            test on this transactive neighbor connection.        -   SystemManager=(53—System ManagerID)—conduct the test on this            system manager connection.        -   Asset=(2—AssetID)—conduct the test on this asset connection.        -   LocalInformation=(48—Local InformationID)—conduct the test            on this local information connection.    -   Test Logic        -   If upon checking attribute 32—Connection Status for a            connection, this connection is found to be in either state            “3” (3—Connected) or “4” (4—Lost Connection), then            -   Test passed—(S1) The Connected and Lost Connection                states, by definition, pass the Connection Configuration                Test        -   For each configured 52—Transactive Neighbor ID, if any of            the attributes 10—Receive TIS Source, 11—Receive TFS Source,            12—Send TIS Targets, 13—Send TFS Targets, 32—Connection            Status, or 29—Connection Partner Type have not been            configured, then            -   Test failed—(F1) Transactive neighbor connection is not                configured            -   Set attribute 32—Connection Status=“1” (connection state                1—Listed) for this connection.        -   For each configured 53—System Manager ID, if either of the            attributes 32—Connection Status or 29—Connection Partner            Type have not been configured, then            -   Test failed—(F2) System manager connection is not                configured            -   Set attribute 32—Connection Status=“1” (connection state                1—Listed) for this connection.        -   For each configured 2—Asset ID, if any of the attributes            6—Toolkit Function, 25—Asset Output Targets, 32—Connection            Status, or 29—Connection Partner Type have not been            configured, then            -   Test failed—(F3) Asset connection is not configured            -   Set 32—Connection Status=“1” (connection state 1—Listed)                for this connection.        -   For each configured 48—Local Information ID, if any of the            attributes 26—Local Information Source, 32—Connection            Status, or 29—Connection Partner Type have not been            configured, then            -   Test failed—(F4) Local information connection is not                configured            -   Set 32—Connection Status=“1” (connection state 1—Listed)                for this connection.        -   Otherwise            -   Test passed—(S2)            -   Set 32—Connection Status=“2” (connection state                2—Configured) for this connection.

Connect( ) Command—directs a configured connections to be completedbetween this transactive node and one of its connection partners.

-   -   Command Parameters        -   Connection=([All/Connection ID])—identifies one connection            that is to be completed from this transactive node to a            configured connection with a transactive neighbor, system            manager, asset, or local information source. If the            parameter “All” is used, the transactive node should attempt            to apply the command logic sequentially to every configured            connection (e.g., every connection for which a            52—Transactive Neighbor ID, 53—System Manger ID, 2—Asset ID,            or 48—Local Information ID has been configured).    -   Command Logic        -   If the entity that made this command is not the local system            manager and if the entity has not been explicitly given            permission to make this system management command among the            commands in its 31—Connection Partner's System Management            Permissions, then reply            -   “Command failed—(F1) Permissions do not include this                command.”        -   If the Connection ID parameter of this command cannot be            recognized from among the sets of configured 52—Transactive            Neighbor ID, 52—System Manager ID, 2—Asset ID, or 48—Local            Information ID at this transactive node, then reply            -   “Command failed—(F2) Connection ID was not recognized                from configured connections.”        -   If the entity making this command is not among the            30—Entities Permitted to modify this Connection for the            referenced connection, then reply            -   “Command failed—(F3) Entity does not have permission to                change this connection.”        -   If upon review of its 32—Connection Status, the referenced            connection is determined to be in its 3—Connected state,            then reply            -   “Command succeeded—(S1) Connection was already                completed.”        -   If upon review of its 32—Connection Status, the referenced            connection is determined to be in its 1—Listed state, then            reply            -   “Command failed—(F4) Connection cannot be completed from                present connection state.”        -   If the given connection cannot be completed for any other            reason, reply            -   “Command failed—(F5) Unknown reason”            -   If 32—Connection Status=“3” (connection status                3—Connected), then set 32—Connection Status=“2”                (connection state 2—Configured) for the referenced                connection.        -   Otherwise,            -   Reply, “Command succeeded—(S2)”            -   Complete the referenced connection            -   Set 32—Connection Status=“3” (connection state                3—Connected) for the referenced connection.

Disconnect( ) Command—system management command by which a transactivenode is asked to disconnect a connection between this transactive nodeand one of its connection partners.

-   -   Command Parameters        -   Connection=([All/Connection ID])—identifies one connection            that is to be disconnected between this transactive node and            a transactive neighbor, system manager, asset, or local            information source. If the parameter “All” is used, the            transactive node should attempt to apply the command logic            sequentially to every configured connection (e.g., every            connection for which a 52—Transactive Neighbor ID, 53—System            Manger ID, 2—Asset ID, or 48—Local Information ID has been            configured).    -   Command Logic        -   If the entity that made this command is not the local system            manager and if the entity has not been explicitly given            permission to make this system management command among the            commands in its 31—Connection Partner's System Management            Permissions, then reply            -   “Command failed—(F1) Permissions do not include this                command.”        -   If the Connection ID parameter of this command cannot be            recognized from among the sets of configured 52—Transactive            Neighbor ID, 52—System Manager ID, 2—Asset ID, or 48—Local            Information ID at this transactive node, then reply            -   “Command failed—(F2) Connection ID was not recognized                from configured connections.”        -   If the entity making this command is not among the            30—Entities Permitted to modify this Connection for the            referenced connection, then reply            -   “Command failed—(F3) Entity does not have permission to                change this connection.”        -   If upon review of its 32—Connection Status, the referenced            connection is determined to be in either its 2—Configured or            1—Listed state, then reply            -   “Command succeeded—(S1) Connection was already                disconnected.”        -   If the given connection cannot be completed for any other            reason, reply            -   “Command failed—(F4) Unknown reason”        -   Otherwise,            -   Reply, “Command succeeded—(S2)”            -   Disconnect the referenced connection            -   Set 32—Connection Status=“2” (connection state                2—Configured) for the referenced connection.

Loss of Connection Event( )—a diagnostic process at this transactivenode observes the health and activity of each connection. If theconnection should fail, the diagnostic process initiates a Loss ofConnection Event. This event transitions the respective connection intoa temporary Lost Connection state, from which the ramifications of theevent may be addressed and handled. This transactive node is permittedto remain in its Operational state in the meantime, according to thelogic of the present state model.

-   -   Event Parameters—None.    -   Said “diagnostic process” should apply to a connection that is        in either its 3—Connected or 4—Lost Connection states. The means        by which a connection may be monitored may involve one or more        of these suggested mechanisms:        -   Observation of interactions with connection partners that            occur or fail to occur at times that such interactions were            anticipated        -   Occasional “pings” of connection partners to determine            whether they remain communicative        -   A “heartbeat” mechanism that ensures connection partners            that a connection remains active. (A “heartbeat” between            transactive neighbors should be bidirectional because both            transactive neighbors will share this to monitor the            connection. Other connection partners may not be transactive            nodes, in which case the heartbeat may be unidirectional to            satisfy the transactive node)    -   Event Handler Logic        -   This logic applies to a connection that is in its            3—Connected state.        -   If a connection is no longer working based on findings from            the diagnostic process,            -   Set 32—Connection Status=“4” (connection state 4—Lost                Connection) for this connection.        -   Add a record of the UTC standard time at which the event            occurred into the 55—Lost Connection Event Buffer.        -   Start a timer to keep track of how long this connection            remains in its Lost Connection state.

Re-Establish Connection Event( )—a diagnostic process recognizes that aconnection has become restored for a connection that was in its LostConnection state. The connection reverts to its Connected state.

-   -   Event Parameters—None.    -   This event handler should use the same diagnostic process that        was described above for the Loss of Connection Event.    -   Event Handler Logic        -   This logic applies only to a connection that is in its            temporary Lost Connection state.        -   If prior to the occurrence of a Terminate Connection Event(            ), this transactive node recognizes that a lost connection            has become restored, then            -   Set 32—Connection Status=“3” (connection state                3—Connected) for the respective connection            -   Stop the Loss of Connection Event timer.            -   Re-commence interactions with the respective connection                partner via this connection.    -   Terminate Connection Event( )        -   Event Parameters—None.        -   This event handler should use the same diagnostic process            that was described above for the Loss of Connection Event            and Re-Establish Connection Event.        -   Event Handler Logic            -   This logic applies to a connection that is in its Lost                Connection state.            -   If the Loss of Connection Event timer exceeds                54—Connection Timeout Period for this connection, then                -   Set 32—Connection Status=“2” (connection state                    2—Configured) for this connection                -   Issue alert, “(A1)—Terminate Connection Event                    occurred by timeout for connection [Connection ID].”            -   If upon reviewing the contents of the 55—Loss of                Connection Event Buffer it is observed that the numbers                of Loss of Connection Events in the last hour has                exceeded the criteria in 56—Allowed Frequency of Loss of                Connection Events, then                -   Set 32—Connection Status=“2” (connection state                    2—Configured) for this connection                -   Issue alert, “(A2)—Terminate Connection Event—Too                    many hourly events for connection [Connection ID].”            -   If upon reviewing the contents of the 55—Loss of                Connection Event Buffer the numbers of Loss of                Connection Events in the last 24 hours has exceeded the                criteria in 56—Allowed Frequency of Loss of Connection                Events, then                -   Set 32—Connection Status=“2” (connection state                    2—Configured) for this connection                -   Issue alert, “(A3)—Terminate Connection Event—Too                    many daily events for connection [Connection ID].”

6.1.15 Connection State Transition Table

Table 20 is the state transition table for the four types of connectionsthat are to be managed by a transactive node. Refer to the diagrammaticrepresentation of the connection state transitions in FIG. 30 thatshould represent these same state transitions.

TABLE 20 State Transition Table for Connections of Four Types Acts UponProducing Info. Internal Current To Set Next On the Gathered & RowFunction State Using Input Attributes State Output Condition Recorded11a Connection 1 - Listed Connection 1 - Listed Connection Test failed -Connection Configuration attributes 2 - event log [(F1) Transactiveevent log Test Asset ID, entry neighbor entry Failed 10 - connectionReceive is not TIS configured/ Source, 11 - (F2) System Receive managerTFS connection Source, 12 - is not Sent TIS configured/ Targets, 13 -(F3) Asset Send connection TFS is not Targets, 25 - configured/ Asset(F4) Local Output information Targets, 26 - connection Local is notInformation configured] Source, 32 - Connection Status, 29 - ConnectionPartner Type, 48 - Local Information ID, 52 - Transactive Neighbor ID,and 53 - System Manager ID 11b Configure 1 - Listed Source of Nearly 1 -Listed Reply: Success - Connection command; any “Command (S1) commandcommand connection Succeeded - log entry parameters; attribute (S1)”Filename; may be Action: Run lists of configured. Connectionconfigurable See Configuration attributes the Test (see command Action:Run command definition Configuration definition), for Test connectiondetails. Connection attributes Lists of command 2 - Asset configurablelog entry ID, 30 - attributes Entities may be Permitted found in toModify the this command Connection, definition. 31 - ConnectionPartner's System Management Permissions, 32 - Connection Status, 48 -Local Information ID, 52 - Transactive Neighbor ID, 53 - System ManagerID 11c Disconnect 1 - Listed Source of 1 - Listed Reply: Success -Connection command; “Command (S1) command command succeeded - Connectionlog entry parameters; (S1) already connection Connection disconnectedattributes already 2 - Asset disconnected” ID, Connection 30 - Entitiescommand Permitted log entry to Modify this Connection, 31 - ConnectionPartner's System Management Permissions, 32 - Connection Status, 48 -Local Information ID, 52 - Transactive Neighbor ID, 53 - System ManagerID 11d Fail to 1 - Listed Source of 1 - Listed Reply: Command ConnectionConfigure command; “Command failed - command command failed - [(F1)Permissions log entry parameters; [(F1) Permissions do Filename; do notinclude lists of not include this configurable this command/ attributescommand/ (F2) (see (F2) Configure command Configure command definition),command not allowed connection not allowed from attributes fromOperational 2 - Asset Operational state/ ID, 30 - state/ (F3) FileEntities (F3) File cannot be Permitted cannot be found or to Modifyfound or opened/ this opened/ (F7) Entity Connection, (F7) Entity making31 - Connection making command Partner's command does not System doesnot have Management have permission Permissions, permission to configure32 - Connection to configure this Status, this connection/ 48 - Localconnection/ (F8) Command Information (F8) Command did not ID, did notaddress 52 - Transactive address known Neighbor known transactive ID,transactive neighbor 53 - System neighbor connection Manager connectionattributes/ ID attributes/ (F9) (F9) Command Command did not did notaddress address known known system system manager manager connectionconnection attributes/ attributes/ (F10) Command (F10) Command did didnot address not address known known asset asset connection connectionattributes/ attributes/ (F11) Command (F11) Command did did not addressnot address known local known local information information connectionconnection attributes/ attributes/ (F6) (F6) Unknown Unknown reason]reason]” Connection command log entry 11e Fail to 1 - Listed Source of1 - Listed Reply: Failure - Connection Connect command; “Command [(F1)Permissions command command failed - do log entry parameters; [(F1)Permissions not include connection do this attributes not includecommand/ 2 - Asset this (F2) Connection ID, command/ ID 30 - Entities(F2) Connection was not Permitted ID recognized to Modify was not fromthis recognized configured Connection, from connections/ 31 - Connectionconfigured (F3) Entity Partner's connections/ does not System (F3)Entity have Management does not permission Permissions, have to change32 - Connection permission this Status, to change connection/ 48 - Localthis (F4) Connection Information connection/ cannot be ID, (F4)Connection completed 52 - Transactive cannot be from Neighbor completedpresent ID, from connection 53 - System present state] Managerconnection ID state]” Connection command log entry 11f Fail to 1 -Listed Source of 1 - Listed Reply: Failure - Connection Disconnectcommand; “Command [(F1) Permissions command command failed - do logentry parameters; [(F1) Permissions not include connection do thisattributes not include command/ 2 - Asset this (F2) Connection ID,command/ ID 30 - Entities (F2) Connection was not Permitted IDrecognized to Modify was not from this recognized configured Connection,from connections/ 31 - Connection configured (F3) Entity Partner'sconnections/ does not System (F3) Entity have Management does notpermission Permissions, have to change 32 - Connection permission thisStatus, to change connection/ 48 - Local this (F4) Unknown Informationconnection/ reason] ID, (F4) Unknown 52 - Transactive reason]” NeighborConnection ID, command 53 - System log entry Manager ID 12 Connection1 - Listed Connection 32 - 2 - Configured Connection Test ConnectionConfiguration attributes 2 - Connection event log passed - event logTest Asset ID, Status = entry (S2) entry Passed 10 - “2” Normal Receive(connection pass TIS state condition Source, 11 - 2 - Configured)Receive TFS Source, 12 - Sent TIS Targets, 13 - Send TFS Targets, 25 -Asset Output Targets, 26 - Local Information Source, 32 - ConnectionStatus, 29 - Connection Partner Type, 48 - Local Information ID, 52 -Transactive Neighbor ID, and 53 - System Manager ID 21 Connection 2 -Configured Connection 1 - Listed Connection Test failed - ConnectionConfiguration attributes 2 - event log [(F1) Transactive event log TestAsset ID, entry neighbor entry Failed 10 - connection Receive is not TISconfigured/ Source, 11 - (F2) System Receive manager TFS connectionSource, 12 - is not Sent TIS configured/ Targets, 13 - (F3) Asset Sendconnection TFS is not Targets, 25 - configured/ Asset (F4) Local Outputinformation Targets, 26 - connection Local is not Informationconfigured] Source, 32 - Connection Status, 29 - Connection PartnerType, 48 - Local Information ID, 52 - Transactive Neighbor ID, and 53 -System Manager ID 22a Configure 2 - Configured Source of Nearly 2 -Configured Reply: Success - Connection command; any “Command (S1)command command connection Succeeded - log entry parameters; attribute(S1)” Filename; may be Action: Run lists of configured. Connectionconfigurable See Configuration attributes the Test (see command Action:Run command definition Configuration definition), for Test connectiondetails. Connection attributes Lists of command 2 - Asset configurablelog entry ID, 30 - attributes Entities may be Permitted found in toModify the this command Connection, definition. 31 - ConnectionPartner's System Management Permissions, 32 - Connection Status, 48 -Local Information ID, 52 - Transactive Neighbor ID, 53 - System ManagerID 22b Connection 2 - Configured Connection 2 - Configured ConnectionTest Connection Configuration attributes 2 - event log passed - eventlog Test Asset ID, entry (S2) entry Passed 10 - Normal Receive pass TIScondition Source, 11 - Receive TFS Source, 12 - Sent TIS Targets, 13 -Send TFS Targets, 25 - Asset Output Targets, 26 - Local InformationSource, 32 - Connection Status, 29 - Connection Partner Type, 48 - LocalInformation ID, 52 - Transactive Neighbor ID, and 53 - System Manager ID22c Disconnect 2 - Configured Source of 2 - Configured Reply: Success -Connection command; “Command (S1) command command succeeded - Connectionlog entry parameters; (S1) already connection Connection disconnectedattributes already 2 - Asset disconnected” ID, Connection 30 - Entitiescommand Permitted log entry to Modify this Connection, 31 - ConnectionPartner's System Management Permissions, 32 - Connection Status, 48 -Local Information ID, 52 - Transactive Neighbor ID, 53 - System ManagerID 22d Fail to 2 - Configured Source of 2 - Configured Reply: CommandConnection Configure command; “Command failed - command command failed -[(F1) Permissions log entry parameters; [(F1) Permissions do Filename;do not include lists of not include this configurable this command/attributes command/ (F2) (see (F2) Configure command Configure commanddefinition), command not allowed connection not allowed from attributesfrom Operational 2 - Asset Operational state/ ID, 30 - state/ (F3) FileEntities (F3) File cannot be Permitted cannot be found or to Modifyfound or opened/ this opened/ (F7) Entity Connection, (F7) Entity making31 - Connection making command Partner's command does not System doesnot have Management have permission Permissions, permission to configure32 - Connection to configure this Status, this connection/ 48 - Localconnection/ (F8) Command Information (F8) Command did not ID, did notaddress 52 - Transactive address known Neighbor known transactive ID,transactive neighbor 53 - System neighbor connection Manager connectionattributes/ ID attributes/ (F9) (F9) Command Command did not did notaddress address known known system system manager manager connectionconnection attributes/ attributes/ (F10) Command (F10) Command did didnot address not address known known asset asset connection connectionattributes/ attributes/ (F11) Command (F11) Command did did not addressnot address known local known local information information connectionconnection attributes/ attributes/ (F6) (F6) Unknown Unknown reason]reason]” Connection command log entry 22e Fail to 2 - Configured Sourceof 2 - Configured Reply: Failure - Connection Connect command; “Command[(F1) Permissions command command failed - do log entry parameters;[(F1) Permissions not include connection do this attributes not includecommand/ 2 - Asset this (F2) Connection ID, command/ ID 30 - Entities(F2) Connection was not Permitted ID recognized to Modify was not fromthis recognized configured Connection, from connections/ 31 - Connectionconfigured (F3) Entity Partner's connections/ does not System (F3)Entity have Management does not permission Permissions, have to change32 - Connection permission this Status, to change connection/ 48 - Localthis (F5) Unknown Information connection/ reason] ID, (F5) Unknown 52 -Transactive reason]” Neighbor Connection ID, command 53 - System logentry Manager ID 22f Fail to 2 - Configured Source of 2 - ConfiguredReply: Failure - Connection Disconnect command; “Command [(F1)Permissions command command failed - do log entry parameters; [(F1)Permissions not include connection do this attributes not includecommand/ 2 - Asset this (F2) Connection ID, command/ ID 30 - Entities(F2) Connection was not Permitted ID recognized to Modify was not fromthis recognized configured Connection, from connections/ 31 - Connectionconfigured (F3) Entity Partner's connections/ does not System (F3)Entity have Management does not permission Permissions, have to change32 - Connection permission this Status, to change connection/ 48 - Localthis (F4) Unknown Information connection/ reason] ID, (F4) Unknown 52 -Transactive reason]” Neighbor Connection ID, command 53 - System logentry Manager ID 23 Connect 2 - Configured Source of 32 - 3 - ConnectedReply: Command Connection command; Connection “Command succeeded -command command Status = succeeded - (S2) log entry parameters; “3”(S2)” Normal connection (connection Connection completion attributesstate command 2 - Asset 3 - log entry ID, Connected) 30 - EntitiesPermitted to Modify this Connection, 31 - Connection Partner's SystemManagement Permissions, 32 - Connection Status, 48 - Local InformationID, 52 - Transactive Neighbor ID, 53 - System Manager ID 32 Disconnect3 - Connected Source of 32 - 2 - Configured Reply: Success - Connectioncommand; Connection “Command (S2) command command Status = succeeded -Normal log entry parameters; “2” (S2)” completion connection (connectionAction: attributes state Sever 2 - Asset 2 - Configured) connection ID,to this 30 - Entities communication Permitted partner to ModifyConnection this command Connection, log entry 31 - Connection Partner'sSystem Management Permissions, 32 - Connection Status, 48 - LocalInformation ID, 52 - Transactive Neighbor ID, 53 - System Manager ID 33aConnection 3 - Connected Connection 3 - Connected Connection TestConnection Configuration attributes 2 - event log passed - event logTest Asset ID, entry (S1) entry Passed 10 - Connection Receive alreadyTIS completed Source, 11 - Receive TFS Source, 12 - Sent TIS Targets,13 - Send TFS Targets, 25 - Asset Output Targets, 26 - Local InformationSource, 32 - Connection Status, 29 - Connection Partner Type, 48 - LocalInformation ID, 52 - Transactive Neighbor ID, and 53 - System Manager ID33b Connect 3 - Connected Source of 3 - Connected Reply: CommandConnection command; “Command succeeded - command command succeeded -(S1) log entry parameters; (S1) Connection connection Connection alreadyattributes already made 2 - Asset made” ID, Connection 30 - Entitiescommand Permitted log entry to Modify this Connection, 31 - ConnectionPartner's System Management Permissions, 32 - Connection Status, 48 -Local Information ID, 52 - Transactive Neighbor ID, 53 - System ManagerID 33c Fail to 3 - Connected Source of 3 - Connected Reply: CommandConnection Configure command; “Command failed - command command failed -[(F1) Permissions log entry parameters; [(F1) Permissions do Filename;do not include lists of not include this configurable this command/attributes command/ (F2) (see (F2) Configure command Configure commanddefinition), command not allowed connection not allowed from attributesfrom Operational 2 - Asset Operational state/ ID, 30 - state/ (F12)Configure Entities (F12) Configure command Permitted command not allowedto Modify not allowed from this from connected Connection, connectedconnection 31 - Connection connection states] Partner's states]” SystemConnection Management command Permissions, log entry 32 - ConnectionStatus, 48 - Local Information ID, 52 - Transactive Neighbor ID, 53 -System Manager ID 33d Fail to 3 - Connected Source of 3 - ConnectedReply: Failure - Connection Connect command; “Command [(F1) Permissionscommand command failed - do log entry parameters; [(F1) Permissions notinclude connection do this attributes not include command/ 2 - Assetthis (F2) Connection ID, command/ ID 30 - Entities (F2) Connection wasnot Permitted ID recognized to Modify was not from this recognizedconfigured Connection, from connections/ 31 - Connection configured (F3)Entity Partner's connections/ does not System (F3) Entity haveManagement does not permission Permissions, have to change 32 -Connection permission this Status, to change connection/ 48 - Local this(F5) Unknown Information connection/ reason] ID, (F5) Unknown 52 -Transactive reason]” Neighbor Connection ID, command 53 - System logentry Manager ID 33e Fail to 3 - Connected Source of 3 - ConnectedReply: Failure - Connection Disconnect command; “Command [(F1)Permissions command command failed - do log entry parameters; [(F1)Permissions not include connection do this attributes not includecommand/ 2 - Asset this (F2) Connection ID, command/ ID 30 - Entities(F2) Connection was not Permitted ID recognized to Modify was not fromthis recognized configured Connection, from connections/ 31 - Connectionconfigured (F3) Entity Partner's connections/ does not System (F3)Entity have Management does not permission Permissions, have to change32 - Connection permission this Status, to change connection/ 48 - Localthis (F4) Unknown Information connection/ reason] ID, (F4) Unknown 52 -Transactive reason]” Neighbor Connection ID, command 53 - System logentry Manager ID 34 Loss of 3 - Connected Diagnostic 32 - 4 - LostConnection Diagnostic Connection Connection system Connection Connectionevent log system event log Event information Status = entry detects thata entry from the “4” connection system that (connection to a overseesstate connection connections; 4 - Lost partner is identity Connection),dead while of affected and that connection; 55 - connection and Loss ofis in its connection Connection Connected attributes Event state 18 -Time, Buffer 32 - Connection Status 42a Terminate 4 - Lost Diagnostic32 - 2 - Configured “Alert - [(A1) Terminate Connection ConnectionConnection system Connection [(A1) Terminate Connection event log Eventinformation Status = Connection Event entry from the “2” Event occurredby system that (connection occurred by timeout for oversees statetimeout for connection connections; 2 - Configured) connection[Connection identity [Connection ID]/ of affected ID]/ (A2) Terminateconnection; (A2) Terminate Connection and Connection Event - connectionEvent - Too many attributes Too many hourly 18 - Time, hourly events for32 - Connection events for connection Status, connection [Connection54 - Connection [Connection ID]/ Timeout ID]/ (A3) Terminate Period,(A3) Terminate Connection 55 - Loss Connection Event - of Event - Toomany Connection Too many daily Event daily events for Buffer, events forconnection 56 - Allowed connection [Connection Frequency [ConnectionID]] of Loss of ID]]” Connection Connection Events event log entry 42bDisconnect 4 - Lost Source of 32 - 2 - Configured Reply: Success -Connection Connection command; Connection “Command (S2) command commandStatus = succeeded - Normal log entry parameters; “2” (S2)” completionconnection (connection Action: attributes state Sever 2 - Asset 2 -Configured) connection ID, to this 30 - Entities communication Permittedpartner to Modify Connection this command Connection, log entry 31 -Connection Partner's System Management Permissions, 32 - ConnectionStatus, 48 - Local Information ID, 52 - Transactive Neighbor ID, 53 -System Manager ID 43a Connect 4 - Lost Source of 32 - 3 - ConnectedReply: Command Connection Connection command; Connection “Commandsucceeded - command command Status = succeeded - (S2) log entryparameters; “3” (S2)” Normal connection (connection Connectioncompletion attributes state command 2 - Asset 3 - log entry ID,Connected) 30 - Entities Permitted to Modify this Connection, 31 -Connection Partner's System Management Permissions, 32 - ConnectionStatus, 48 - Local Information ID, 52 - Transactive Neighbor ID, 53 -System Manager ID 43b Re- 4 - Lost Diagnostic 32 - 3 - Connected Action:Re- Diagnostic Connection Establish Connection system Connectionestablish system event log Connection information Status = interface todetects that entry Event from the “3” respective a broken system that(connection connection connection oversees state partner. to aconnections; 3 - Connection connection identity Connected) event logpartner has of affected entry become re- connection; established andwhile that connection connection attributes is in its Lost 18 - Time,Connection 32 - Connection state Status, and 54 - Connection TimeoutPeriod 44a Connection 4 - Lost Connection 4 - Lost Connection TestConnection Configuration Connection attributes 2 - Connection event logpassed - event log Test Asset ID, entry (S1) entry Passed 10 -Connection Receive already TIS completed Source, 11 - Receive TFSSource, 12 - Sent TIS Targets, 13 - Send TFS Targets, 25 - Asset OutputTargets, 26 - Local Information Source, 32 - Connection Status, 29 -Connection Partner Type, 48 - Local Information ID, 52 - TransactiveNeighbor ID, and 53 - System Manager ID 44b Fail to 4 - Lost Source of4 - Lost Reply: Command Connection Configure Connection command;Connection “Command failed - command command failed - [(F1) Permissionslog entry parameters; [(F1) Permissions do Filename; do not includelists of not include this configurable this command/ attributes command/(F2) (see (F2) Configure command Configure command definition), commandnot allowed connection not allowed from attributes from Operational 2 -Asset Operational state/ ID, 30 - state/ (F12) Configure Entities (F12)Configure command Permitted command not allowed to Modify not allowedfrom this from connected Connection, connected connection 31 -Connection connection states] Partner's states]” System ConnectionManagement command Permissions, log entry 32 - Connection Status, 48 -Local Information ID, 52 - Transactive Neighbor ID, 53 - System ManagerID 44c Fail to 4 - Lost Source of 4 - Lost Reply: Failure - ConnectionConnect Connection command; Connection “Command [(F1) Permissionscommand command failed - do log entry parameters; [(F1) Permissions notinclude connection do this attributes not include command/ 2 - Assetthis (F2) Connection ID, command/ ID 30 - Entities (F2) Connection wasnot Permitted ID recognized to Modify was not from this recognizedconfigured Connection, from connections/ 31 - Connection configured (F3)Entity Partner's connections/ does not System (F3) Entity haveManagement does not permission Permissions, have to change 32 -Connection permission this Status, to change connection/ 48 - Local this(F5) Unknown Information connection/ reason] ID, (F5) Unknown 52 -Transactive reason]” Neighbor Connection ID, command 53 - System logentry Manager ID 44d Fail to 4 - Lost Source of 4 - Lost Reply:Failure - Connection Disconnect Connection command; Connection “Command[(F1) Permissions command command failed - do log entry parameters;[(F1) Permissions not include connection do this attributes not includecommand/ 2 - Asset this (F2) Connection ID, command/ ID 30 - Entities(F2) Connection was not Permitted ID recognized to Modify was not fromthis recognized configured Connection, from connections/ 31 - Connectionconfigured (F3) Entity Partner's connections/ does not System (F3)Entity have Management does not permission Permissions, have to change32 - Connection permission this Status, to change connection/ 48 - Localthis (F4) Unknown Information connection/ reason] ID, (F4) Unknown 52 -Transactive reason]” Neighbor Connection ID, command 53 - System logentry Manager ID

6.1.16 Log Entries

The state transition tables in this section have consistently indicatedoutputs to a log table. It will be good practice to create a log entryrecord for each command and event that is encountered by the transactivenode and its connections. Instead of defining each log entry at thepoint that it was introduced in the state transition tables, it may bepreferred to establish practices for the contents of these records basedon their types and by whether they affect the transactive state model orthat of the transactive node's connections:

-   -   1. Command log entry—to be recorded each time a transactive node        system management command is received and responded.        -   {Source of the command, time received, command ID, command            parameters, 5—Node Version, 7—Node Status after the command,            completion condition}    -   2. Connection command log entry—to be recorded each time a        connection system management command is received and responded.        -   {Source of the command, time received, command ID, target            connection ID, 32—Connection Status after the command,            completion condition}    -   3. Event log entry—to be recorded each time a transactive node        event occurs and is responded to.        -   {Event time, event ID, 5—Node Version, 7—Node Status after            the event, completion condition}    -   4. Connection event log entry—to be recorded each time a        connection event occurs and is responded to.        -   {Event time, event ID, target connection ID, 32—Connection            Status after the event, completion condition}    -   5. Test log entry—to be recorded each time a transactive node        test occurs and is responded to.        -   {Test time, test ID, 5—Node Version, 7—Node Status after the            test, completion condition}    -   6. Connection test log entry—to be recorded each time a        connection test occurs and is responded to.        -   {Test time, test ID, target connection ID, 32—Connection            Status after the test, completion condition

6.1.17 Operational Sub-States Table

The table below represents that state transitions of a transactive nodethat has been configured, connected and is now in the overalloperational state and status. Note that there is no start or final statein this table. All states may be intermediary. Refer to the toolkitframework for the algorithmic framework facilitated by this part of thestate model.

TABLE 21 State Transition Model for Transactive Nodes within anOperational State Acts Info. Upon By Producing Gathered Internal CurrentSetting Using Next On the and Row Function State Attributes Inputs StateOutput Condition Recorded A1 Receive Operational 7 TIS TIS U 1, 7. 18,TIS (Listening) Message Received Received TIS message A2 FormulaOperational 7 Attribute TIS Stop TIS 1, 7, 18, te TIS (Listening) 23(TIS Processed TIS Timer > Processed Buffer) Timer, TIS TIS OutgoingTimer message TIS Max or Message(s) TIS received from all inputs A3Receive Operational 7 TFS TFS U 1, 7, 18 TFS (Listening) MessageReceived A4 TFS Operational 7 Attribute TFS Stop TFS (1), (7),(Listening) 24 (TFS Processed TFS Timer > (18), Buffer) Timer, TFSProcessed Outgoing Timer TFS TFS Max or message Messages TFS receivedfrom all inputs. A5 Update TIS 7, 23 TIS Operational Start No TIS (1),(7), TIS Received Message (Listening) TIS Receive (18), 23 Buffer TimerError, and Start TIS Timer if it is not already running. A6 Handle TIS 7TIS Operational Non- TIS (1), (7), Non- Received Message (Listening)fatal TIS Receive (18) fatal TIS Receive Error Receive Error Error A6aHandle TIS 7 TIS Stopped Fatal Fatal TIS (1), (7), Fatal ReceivedMessage TIS Receive (18) TIS Receive Error Receive Error Error A7 SendTIS 7 Outgoing Operational TIS Send TIS (1), (7), TIS Processed TIS(Listening) Message(s) if and (18), Sent Messages to each only if a TISneighbor TIS has messages not already been sent within the Time IntervalA7a Send Operational 7 Outgoing Operational TIS Send TIS (1), (7), TIS(Listening) TIS (Listening) Receive if and (18), Sent Messages Error,only if TIS TIS any messages Message(s) inputs to each from neighborneighbors have not been received within the time interval A7b Handle TIS7 TIS TIS Recovery Non-fatal (1), (7), non- Processed ProcessingProcessed TIS (18) fatal TIS Error Processing Received processing errorTIS error Message, Generated error A7c Handle TIS 7 TIS Stopped FatalTIS (1), (7), fatal TIS Processed Processing Processing (18) processingError Error Received error TIS Message, Generated error A8 Update TFS 7,24 TFS Operational Start No TFS (1), (7), TFS Received Message(Listening) TFS Receive (18), 24 Buffer Timer Error, and Start TFS timerif it is not already running A9 Handle TFS 7 TFS Operational Non- TFS(1), (7), Non- Received Message (Listening) fatal Receive (18) fatal TFSError TFS Receive Receive Error Error A9a Handle TFS 7 TFS Stopped FatalFatal (1), (7), Fatal Received Message TFS TFS (18) TFS Receive ReceiveReceive Error Error Error A10 Send TFS 7 Outgoing Operational TFS Send(1), (7), TFS Processed TFS (Listening) Message(s) TFS if (18), SentMessages to each and only TFS neighbor if a TFS messages has not alreadybeen sent within the time interval. A10a Send Operational 7 OutgoingOperational TFS Send (1), (7), TFS (Listening) TFS (Listening) ReceiveTFS if (18), Sent Messages Error, and only TFS TFS if any messagesMessage(s) inputs to each from our neighbor neighbors have not beenreceived within the time interval. A11 Handle TFS 7 TFS TFS RecoveryNon-fatal (1), (7), non- Processed Processing Processed TFS (18) fatalError Processing Received TFS error TFS processing Message, errorGenerated error A11a Handle TFS 7 TFS Stopped Fatal (1), (7), fatalProcessed Processing TFS (18) TFS Error Processing Received processingError TFS error Message, Generated error (“U” = unconditional)

6.1.18 Transactive Control Signal Propagation 6.1.18.1 Problem Statement

Transactive control signals (transactive incentive signal andtransactive feedback signal) carry information related to electricalpower supply and demand over a wide area network. The signals traverse anetwork of transactive control nodes to elicit a desired control actionfrom responsive assets in a timely manner. The end-to-end (fromgeneration to end-user customer) transmission time should be less than 3minutes assuming a transactive control hierarchy of 15 levels spanning a1000 mile radius. This translates to roughly 12 seconds (180/15) per hoptime budget including the link transit time. Note that the transactiveincentive signals will start at the bulk generators and continue toend-user customers. The transactive feedback signal will start at theend-use customer and will travel through the transactive controlhierarchy towards bulk generation. While the TIS and the TFS aredecoupled temporally and loosely coupled functionally in the sense thata TFS generation does not have to get triggered by the arrival of a TIS,the two signals still influence each other since the computation of TISand TFS considers the forecasted values for each signal.

The timing model can be purely clock-driven or more asynchronouslyevent-driven. For example, in some embodiments, a set of neighboringtransactive nodes are configured to exchange transactive values with oneanother until the transactive values converge with one another to anacceptable degree (e.g., within a designated percentage of one another(such as 5%, 2%, 1%, or any other desired degree of tolerance)).Further, in such even-driven systems, when a change occurs within atransactive node (e.g., due to a change in local conditions), thetransactive node can be configured to transmit an updated set oftransactive signals when its local transactive signals deviate from thepreviously transmitted signals by more than a relaxation criterion.

If the system becomes highly synchronized, bursts of signals might taxthe system infrastructure. If the system becomes too looselyevent-driven and asynchronous, it becomes more difficult to confirm thatsignals will have been conveyed. There is probably some flexibilityallowable between these extremes, and the design in this appendixfacilitates some flexibility. Regardless, the timing model shouldrecognize that the “conversation” of these signals necessarily changesduring the transition from one update interval to the next because theset of future intervals change during this transition.

FIG. 31 is a diagram 3100 showing TIS and TFS generation beingdecoupled. The processing of TIS and TFS inputs is performed inreference to the basic 5-minute interval structure that is UTCreferenced.

6.1.18.2 Transactive Node Object Model Attributes Summary

A set of ten (and in some embodiments, mandatory), configurableattributes B1-B10 are defined below in Table 22.

6.1.18.3 One exemplary Approach

-   -   1. Transactive control nodes of the Demonstration use time        synchronization with a tolerance of 200 ms. This is readily        achievable using either NTP or SNTP. The synchronization is        useful to align transactive signal intervals as well as ease of        correlation of data collection and event logs.    -   2. Each transactive control node has two transactive signal        timers: TIS_TIMER and TFS_TIMER. These timers are started upon        receipt of a TIS or TFS respectively and impose a delay to allow        for arrival of more signals before processing occurs (12 second        default value).    -   3. Each transactive control node has two “hold-down” timers:        TIS_HOLD_DOWN_TIMER and TFS_HOLD_DOWN_TIMER. These timers lock        out additional processing to prevent race conditions in the mesh        segment of a network of transactive control nodes. (30 second        default value). The value should be >=TIS_TIMER and TFS_TIMER        respectively.    -   4. Each transactive control node has a transactive signal        watchdog timer (WATCHDOG_TIMER), which is configured to fire off        every T_period (300 default value) seconds. It is desirable that        the WATCHDOG_TIMER be less than or equal to the value of the        smallest interval (currently 300 seconds) used in the        communication of the transactive signals.    -   5. Upon startup, a transactive control node starts the        transactive signal watchdog timer. It is recommended that the        watchdog timer be aligned with the transactive signal update        intervals. For example, if the transactive signal intervals are        {6:00, 6:05, 6:10, . . . } then the watchdog timer is        recommended to also be started at 6:00 and fire-off every 300        seconds.    -   6. When the transactive signal watchdog timer expires, if        WATCHDOG_TIMER_SIGNAL_GEN_ALWAYS_ON configuration variable is        set to TRUE then the node will send TIS and TFS packets to        neighboring transactive control nodes. If        WATCHDOG_TIMER_SIGNAL_GEN_ALWAYS_ON is set to FALSE and if no        signal driven events have taken place in the last interval then        the node sends TIS and TFS packets to neighboring transactive        control nodes connected to this node. Then, the node restarts        the global timer.    -   7. When the node receives a TIS packet, it starts the TIS_TIMER        (if it is not already started), and stores the TIS packet in the        local TIS store. The TIS_TIMER represents a transactive signal        collection period to allow the transactive control node to        receive all possible signals from its neighbors. (Each        transactive node typically knows how many transactive neighbors        it has and therefore how many transactive signals it should        expect to receive. In deeper topologies, the TIS_TIMER and        TFS_TIMER will unlikely achieve the desired effect of collecting        all signals prior to calculation because signal path lengths        will be dissimilar for various signals that are to be received.)    -   8. When the node receives a TFS packet, it starts the TFS_TIMER        (if it is not already started), stores the TFS packet in the        local TFS store. The TFS_TIMER represents a transactive signal        collection period to allow the transactive control node to        receive all possible signals from its neighbors.    -   9. When the TIS_TIMER expires, the node performs the transactive        control computation using the most recent TIS and TFS        information stored in its TIS and TFS stores. (Received TIS and        TFS signals will often contribute only a small influence to the        newly calculated TIS and TFS at a transactive node.)    -   10. When TFS_TIMER expires, the node starts performs the        transactive control computation using the most recent TIS and        TFS information stored in its TIS and TFS stores.    -   11. When the node finishes TIS signal computation, it clears the        store and sends a TIS packet to its neighbors (In simulations,        the processing is represented with a delay of 12 seconds). The        TIS_HOLD_DOWN_TIMER is started. No TIS may be sent again until        it expires.    -   12. When the node finishes the TFS signal computation, it clears        the cache and sends a TFS packet to its neighbors (In        simulations, the processing is represented with a delay of 12        seconds). The TFS_HOLD_DOWN_TIMER is started. No TFS may be sent        again until it expires.    -   13. Since the transactive control is a distributed system, there        will be times when transactive control signals arrive during the        hold-down timer or outside the TIS/TFS timer data collection        periods. TIS and TFS signals also may arrive at different parts        of the time interval. When a new transactive control signal is        received and the corresponding transactive control signal        computation is performed, one may find that the resulting        TIS/TFS values show no significant changes to the previously        sent values in the same “interval.” In this case, the        transactive control node is recommended to omit or delay the        transmission of a new TIS/TFS value. This added feature allows        further reductions of both communications chatter and        computational cycles. This behavior is controlled by means of        two configuration variables:        -   TIS_SIGNAL_SUPPRESS_IF_NO_CHANGE and        -   TFS_SIGNAL_SUPPRESS_IF_NO_CHANGE. If either one of these            variables are set to TRUE, then the node will be perform the            check for no change of the corresponding TIS or TFS signals            and suppress transmission.    -   14. One of the primary inputs to the transactive control node is        the local conditions input. This section encourages inclusion of        triggers for computation and transmission of TIS/TFS based on        changes in the local conditions. The criteria for incorporation        of local conditions will be decided at a later time.

The timers and the operation for an example TIS embodiment areillustrated in diagram 3200 of FIG. 32. The TFS is handled in a similarmanner.

In summary, the following desired behavior is expressed in pseudo codeformat.

Upon node startup:

-   -   Start WATCHDOG_TIMER

Upon receiving a TIS:

-   -   if (TIS_TIMER is not running) && (TIS_HOLD_DOWN_TIMER is not        running) && (!TIS_IN_CALCULATION) {Start TIS_TIMER}    -   Store received TIS

Upon receiving a TFS:

-   -   if (TFS_TIMER is not running) && (TFS_HOLD_DOWN_TIMER is not        running) && (!TIS_IN_CALCULATION) {Start TFS_TIMER}    -   Store received TFS

Upon expiration of TIS_TIMER:

-   -   Stop and clear TIS_TIMER    -   Set TIS_IN_CALCULATION==true)    -   Compute TIS using most recent stored TIS and TFS.    -   If (TIS_SIGNAL_SUPPRESS_IF_NO_CHANGE==FALSE) {Send TIS} else        {check for change in values of computed TIS with the previously        sent TIS. If change {Send TIS} else {do nothing}    -   Set TIS_IN_CALCULATION==false)    -   If (TIS is sent) {Start TIS_HOLD_DOWN_TIMER}

Upon expiration of TFS_TIMER:

-   -   Stop and clear TFS_TIMER    -   Set TFS_IN_CALCULATION==true)    -   Compute TFS using most recent stored TIS and TFS.    -   If (TFS_SIGNAL_SUPPRESS_IF_NO_CHANGE==FALSE) {Send TFS} else        {check for change in values of computed TFS with the previously        sent TFS. If change {Send TFS} else {do nothing}}    -   Set TFS_IN_CALCULATION==false)    -   If (TFS is sent) {Start TFS_HOLD_DOWN_TIMER}

Upon expiration of TIS_HOLD_DOWN_TIMER:

-   -   Stop and clear TIS_HOLD_DOWN_TIMER    -   If (no new TIS) {do nothing}    -   If (new TIS)        -   Set TIS_IN_CALCULATION==true)        -   Compute TIS using most recent stored TIS and TFS.        -   If (TIS_SIGNAL_SUPPRESS_IF_NO_CHANGE==FALSE) {Send TIS} else            {check for change in values of computed TIS with the            previously sent TIS. If change {Send TIS} else {do nothing}            }        -   Set TIS_IN_CALCULATION==false)        -   If (TIS is sent) {Start TIS_HOLD_DOWN_TIMER}

FIG. 33 is a diagram 3300 illustrating an example where a perpetualexchange of signals might become sustained between two transactive nodeneighbors.

Upon expiration of TFS_HOLD_DOWN_TIMER:

-   -   Stop and clear TFS_HOLD_DOWN_TIMER    -   If (no new TFS) {do nothing}    -   If (new TFS)        -   Set TFS_IN_CALCULATION==true)        -   Compute TFS using most recent stored TIS and TFS.        -   If (TFS_SIGNAL_SUPPRESS_IF_NO_CHANGE==FALSE) {Send TFS} else            {check for change in values of computed TIS with the            previously sent TFS}        -   Set TFS_IN_CALCULATION==false)        -   If change {Send TFS} else {do nothing}        -   If (TFS is sent) {Start TFS_HOLD_DOWN_TIMER}

Upon expiration of the WATCHDOG_TIMER:

-   -   If (WATCHDOG_TIMER_SIGNAL_GEN_ALWAYS_ON==TRUE) {        -   If (local_conditions_change==TRUE)∥(TIS/TFS is not computed            in this period) {            -   Recompute TIS/TFS}        -   Send TIS; Send TFS; Start TIS_HOLD_DOWN_TIMER; Start            TFS_HOLD_DOWN_TIMER}    -   If (WATCHDOG_TIMER_SIGNAL_GEN_ALWAYS_ON==FALSE) {        -   If (local_conditions_change==FALSE) && (we sent TIS/TFS in            the last transactive signal interval) {            -   Do nothing}        -   Else {            -   Recompute TIS/TFS            -   Send TIS; Send TFS; Start TIS_HOLD_DOWN_TIMER; Start                TFS_HOLD_DOWN_TIMER}}

TABLE 22 Dictionary of Exemplary Timing Attributes Recommended at aTransactive Node to Facilitate Exchange of Transactive Signals betweenTransactive Neighbors Range of No. Attribute Name Description Role TypeFormat values B1 TIS_TIMER Started upon Allows for arrival Single real —The value 0 receipt of the of more TIS number. (zero) first TIS insignals before disables the the current processing TIS_TIMER. updateoccurs. Helps Default interval (See retard value: 12 s. 9-Updatesuccessive Frequency). transmissions of TIS signals. B2 TFS_TIMERStarted upon Allows for arrival Single real — The value 0 receipt of theof more TFS number. (zero) first TFS in signals before disables the thecurrent processing TFS_TIMER. update occurs. Helps Default interval (Seeretard value: 12 s. 9-Update successive Frequency). transmissions of TFSsignals. B3 TIS_IN_ If set, Certain actions Binary — 0-Not busyCALCULATION indicates that are to be condition calculating the preventedflag. TIS. transactive during this time Dimensionless. 1-Busy node is toavoid calculating engaged in corrupting TIS. recalculating calculatedits TIS value. signals. B4 TFS_IN_ If set, Certain actions Binary —0-Not busy CALCULATION indicates that are to be condition calculatingthe prevented flag. TFS. transactive during this time Dimensionless.1-Busy node is to avoid calculating engaged in corrupting TFS.recalculating calculated its TFS signals. values. B5 TIS_HOLD_ Startedupon Used to Single real — Use of 0 DOWN_TIMER sending a suppressnumber. (zero) as the TIS. transmission of Units: s. value Successiveexcessive TIS disables this TIS may not messages. timer. be Default: 30s. transmitted Timer by this duration transactive should be node untilshorter than after this the update timer has interval expired. indicatedby 9-Update Frequency attribute. B6 TFS_HOLD_ Started upon Used toSingle real — Use of 0 DOWN_TIMER sending a suppress number. (zero) asthe TFS. transmission of Units: s. value Successive excessive TFSdisables this TFS may not messages. timer. be Default: 30 s. transmittedTimer by this duration transactive should be node until shorter thanafter this the update timer has interval expired. indicated by 9-UpdateFrequency attribute. B7 WATCHDOG_ An event Actions, like the Single real— Use of 0 TIMER occurs at this transmission of number. (zero) as theinterval transactive Units: s. value duration and signals and thedisables this is aligned sending of asset timer (e.g., with the controlno action transitions recommendations may be from one to asset inducedby a update systems, may watchdog- interval into be configured to timerevent. the next. occur each time If assigned a (In some the watchdognon-zero embodiments, timer expires. value, this the During testing,duration watchdog the watchdog should be time is timer duration longerthan aligned with may be any of the the update shortened to attributesB1- interval, but speed the rate TIS Timer, that need not at whichB2-TFS be the case observations Timer, B5- in general. If may be takenTIS Hold the watchdog and thereby Down Timer, timer is facilitatetesting or B6-TFS further of a transactive Hold Down specified to node.Timer. (If this occur n is not the seconds case, then (e.g., 15 watchdogseconds) timer events prior to the will occur start of the prior to nextupdate calculating interval, it and can be more transmitting useful totransactive induce signals, and transmission watchdog of transactiveevent signals and induced asset control actions may actions thataccumulate.) are relevant Default for the value: Set pending equal tothe update duration of interval.) the update interval, which is 300 sfor the Demonstration. B8 WATCHDOG_ This attribute If set true, thisLogical Logic 0-False- TIMER_ specifies attribute will conditiontransactive SIGNAL_GEN_ whether cause flag: true/ signals are ALWAYS_ONtransactive transactive false. sent when signals are to signals to bethe watchdog be transmitted upon timer transmitted the occurrenceduration or not when of a watchdog expires only a watchdog timer event;if if timer event set false, only corresponding occurs. the type ofcorresponding transactive transactive signal was signals that not sentwere not sent by during the this transactive expiring node during thewatchdog expiring timer watchdog time duration. interval are to be1-True- transmitted. the default See transactive condition- neighbortransmit TIS connection and TFS attributes 59- transactive TIS Sent Flagsignals upon and 60-TFS the Sent Flag expiration of attributes. thewatchdog timer regardless of whether any transactive signals weretransmitted during the watchdog timer duration that is expiring. B9TIS_SIGNAL_ This attribute This attribute Logical Logic. 0-False-SUPPRESS_IF_ controls TIS and the related condition the NO_CHANGEgeneration. If attribute B10 flag: true/ differences this attribute canreduce the false. between is set true, numbers of newly the redundantcalculated transactive transactive and prior control node signalstransmitted will compare transmitted by TIS signals computed thistransactive are not signal values node. There is relevant. to the littlevalue in 1-True- respective sending default value- previous transactivethe corresponding signals that are difference transactive virtuallyidentical between a signal sent to ones that newly and will not havealready calculated send another been sent. and prior TIS if the Thisattribute transmitted values show works in TIS should be no significantconjunction with compared, changes. attributes C1- and the Default valueC4 (see newly is true. Appendix C calculated concerning the TIS will berelaxation stop transmitted criterion) and only if the attribute B8. (Indifference some was found to embodiments, if be significant. B9 or B10are See true, the Appendix C respective and transactive attributes C1-signals will not C4 for a be sent unless metric of they aresignificance. significantly different from the last ones sent,regardless of the condition of flag B8.) B10 TFS_SIGNAL_ This attributeThis attribute Logical Logic. 0-False- SUPPRESS_IF_ controls TFS and therelated condition the NO_CHANGE generation. If attribute B9 can flag:true/ differences this attribute reduce the false. between is set true,numbers of newly the redundant calculated transactive transactive andprior control node signals transmitted will compare transmitted by TFSsignals computed this transactive are not signal values node. There isrelevant. to the little value in 1-True- respective sending defaultvalue- previous transactive the corresponding signals that aredifference transactive virtually identical between a signal sent to onesthat newly and will not have already calculated send another been sent.and prior TFS if the This attribute transmitted values show works in TFSshould no significant conjunction with be changes. attributes C1-compared, Default value C4 (see and the is true. Appendix C newlyconcerning the calculated relaxation stop TFS will be criterion) andtransmitted attribute B8. only if the difference was found to besignificant. See Appendix C and attributes C1- C4 for a metric ofsignificance.

6.1.19 Transactive Signal Relaxation Stop Criterion 6.1.19.1 Purpose

In certain embodiments, transactive nodes periodically send theirtransactive signals to their neighbors. The timing of thisresponsibility has recently been specified and will become included inreference code implementations of the transactive node model algorithm(TNMA). The timing specification references a relaxation stop criterionbased upon changes observed between the present signal and the mostrecent prior signal that has been calculated and sent by thistransactive node. If the signals are found to have not changed much,this transactive node should not send its calculated signal again duringthe present update interval.

The purpose of this section is to state the criterion by which atransactive node may discern whether it should continue to send out itscalculated transactive signals or not during the present updateinterval.

6.1.19.2 Relaxation Stop Criterion

A relaxation stop criterion can be used under the following assumptions:

-   -   1. Near-term predictions should be known with accuracy.        Prediction inaccuracies and perturbations are somewhat more        acceptable far into the future because one will have many        opportunities to iterate and improve those distant predictions.        Near-term predicted inaccuracies and events may necessitate        additional iterations until the system relaxes to a steady,        negotiated solution.    -   2. A prediction error decreases inversely proportional to some        constant to the power of the number of iterations. The constant        represents the improvement expected from each iteration and will        usually range from [1,2+). If the constant is set to the        conservative value 1, one expects the error not at all to be        improved by iteration. If the number is set to 2, one expects        that each successive iteration should halve the error. It is        conceivable that over-relaxation solutions could allow for        constants larger than 2.    -   3. The impact of an inaccurate prediction is roughly        proportional to the predicted interval's duration.

For each future interval s, define error ε_(s) as the absolutedifference between the present estimate of the value V_(s)(k) and theprior estimate of the value V_(s)(k−1).ε_(s) =|V _(s)(k)−V _(s)(k−1)|  (Eq. C1)

The criterion should be applied consistently to either the value itselfor to a relative representation of the value, which further results individing the result in Eq. C1 by the absolute value of V_(s)(k).

Each error ε_(s) should be factored by a corresponding weighting factorW_(s) to account for the impacts of the duration of each future intervals and the number of iterations that may be reasonably performed on theprediction.

$\begin{matrix}{W_{s} = \frac{D_{s}}{\gamma^{{({t_{s} - t_{0}})}/D}}} & ( {{Eq}.\mspace{11mu}{C2}} )\end{matrix}$

In Eq. C2, D_(s) is the time duration of interval s, and γ is a constant[1,2+) that represents the effectiveness of each iteration, as wasdescribed in bullet #2 above. The term (t_(s)−t₀)/D represents thenumber of iterations that could reasonably be completed if iterationsare conducted after every D constant time interval between the start ofthe predicted interval t_(s) and the present time t₀. For example, thesystem can update its calculations every 5 minutes, so one mightnaturally expect over 12 opportunities for the solution to iterativelyconverge every hour.

The overall relaxation stop criterion may then be stated as a constant Ethat is proportional to the sum of all the weighting factors. Theproportionality constant K represents a conservative “typical” errorε_(s) that would be deemed acceptable. Some trial and error may occur toselect the proportionality constant K that will result in an acceptablenumber of iterations.

The time series has been iterated adequately when the weighted sum oferrors are less than the constant E, in which case iterations should behalted. If, however, the weighted sum of errors is greater than or equalto the constant E, then additional iteration should be conducted untilerrors satisfy the criterion.

$\begin{matrix}{E = {{K{\sum\limits_{S}\; W_{s}}} >^{?}{\sum\limits_{S}\;{W_{s} \cdot ɛ_{s}}}}} & ( {{Eq}.\mspace{11mu}{C3}} )\end{matrix}$

The complete criterion is stated in Eq. C4.

$\begin{matrix}{E = {{K \cdot {\sum\limits_{s = 0}^{S}\;\frac{D_{s}}{\gamma^{{({t_{s} - t_{0}})}/D}}}}\overset{?}{>}{\sum\limits_{s = 0}^{S}\;\frac{D_{s} \cdot ɛ_{s}}{\gamma^{{({t_{s} - t_{0}})}/D}}}}} & ( {{Eq}.\mspace{11mu}{C4}} )\end{matrix}$

An example has been worked through in Appendix A using three differentvalues of constant γ. The example uses a set of intervals from theDemonstration of the type that will be used for its transactive signals.The weighting factors for the series of intervals and at the threeexample values of constant γ have been plotted in graph 3400 of FIG. 34.

Large gamma (e.g. γ=2.0) is shown to discount the importance of error infuture predictions more than small values of gamma (e.g., γ=1.0625). Thejagged curve reflects that long interval durations are weighted morethan short ones, which is relevant for the Demonstrations intervals thatbecome successively longer after the 12^(th), 32^(nd), 50^(th), and54^(th) intervals. The impact of distant future weightings may becomenegligibly small.

FIG. 34 is a graph 3400 showing weighting factors for a set ofDemonstration intervals (IST₀=0:00) using three different values ofconstant γ.

TABLE 23 Example Weighting Factors W_(s) for a Sample Series ofIntervals and for Three Different Gamma Values Sam- D_(s) t_(s)-t_(o)ple (min- (min- W_(s) (#) utes) utes) γ = 2 γ = 1.25 γ = 1.0625 0 51/0/00 0:00 0 5.00E+00 5.00E+00 5.00E+00 1 5 1/0/00 0:05 5 2.50E+004.00E+00 4.71E+00 2 5 1/0/00 0:10 10 1.25E+00 3.20E+00 4.43E+00 3 51/0/00 0:15 15 6.25E−01 2.56E+00 4.17E+00 4 5 1/0/00 0:20 20 3.13E−012.05E+00 3.92E+00 5 5 1/0/00 0:25 25 1.56E−01 1.64E+00 3.69E+00 6 51/0/00 0:30 30 7.81E−02 1.31E+00 3.48E+00 7 5 1/0/00 0:35 35 3.91E−021.05E+00 3.27E+00 8 5 1/0/00 0:40 40 1.95E−02 8.39E−01 3.08E+00 9 51/0/00 0:45 45 9.77E−03 6.71E−01 2.90E+00 10 5 1/0/00 0:50 50 4.88E−035.37E−01 2.73E+00 11 5 1/0/00 0:55 55 2.44E−03 4.29E−01 2.57E+00 12 151/0/00 1:00 60 3.66E−03 1.03E+00 7.25E+00 13 15 1/0/00 1:15 75 4.58E−045.28E−01 6.04E+00 14 15 1/0/00 1:30 90 5.72E−05 2.70E−01 5.04E+00 15 151/0/00 1:45 105 7.15E−06 1.38E−01 4.20E+00 16 15 1/0/00 2:00 1208.94E−07 7.08E−02 3.50E+00 17 15 1/0/00 2:15 135 1.12E−07 3.63E−022.92E+00 18 15 1/0/00 2:30 150 1.40E−08 1.86E−02 2.43E+00 19 15 1/0/002:45 165 1.75E−09 9.51E−03 2.03E+00 20 15 1/0/00 3:00 180 2.18E−104.87E−03 1.69E+00 21 15 1/0/00 3:15 195 2.73E−11 2.49E−03 1.41E+00 22 151/0/00 3:30 210 3.41E−12 1.28E−03 1.18E+00 23 15 1/0/00 3:45 2254.26E−13 6.53E−04 9.80E−01 24 15 1/0/00 4:00 240 5.33E−14 3.35E−048.17E−01 25 15 1/0/00 4:15 255 6.66E−15 1.71E−04 6.81E−01 26 15 1/0/004:30 270 8.33E−16 8.77E−05 5.68E−01 27 15 1/0/00 4:45 285 1.04E−164.49E−05 4.74E−01 28 15 1/0/00 5:00 300 1.30E−17 2.30E−05 3.95E−01 29 151/0/00 5:15 315 1.63E−18 1.18E−05 3.29E−01 30 15 1/0/00 5:30 3302.03E−19 6.03E−06 2.74E−01 31 15 1/0/00 5:45 345 2.54E−20 3.09E−062.29E−01 32 60 1/0/00 6:00 360 1.27E−20 6.32E−06 7.63E−01 33 60 1/0/007:00 420 3.10E−24 4.34E−07 3.69E−01 34 60 1/0/00 8:00 480 7.57E−282.98E−08 1.78E−01 35 60 1/0/00 9:00 540 1.85E−31 2.05E−09 8.60E−02 36 601/0/00 10:00 600 4.51E−35 1.41E−10 4.16E−02 37 60 1/0/00 11:00 6601.10E−38 9.68E−12 2.01E−02 38 60 1/0/00 12:00 720 2.69E−42 6.65E−139.70E−03 39 60 1/0/00 13:00 780 6.57E−46 4.57E−14 4.69E−03 40 60 1/0/0014:00 840 1.60E−49 3.14E−15 2.26E−03 41 60 1/0/00 15:00 900 3.92E−532.16E−16 1.09E−03 42 60 1/0/00 16:00 960 9.56E−57 1.48E−17 5.28E−04 4360 1/0/00 17:00 1020 2.33E−60 1.02E−18 2.55E−04 44 60 1/0/00 18:00 10805.70E−64 7.01E−20 1.23E−04 45 60 1/0/00 19:00 1140 1.39E−67 4.82E−215.96E−05 46 60 1/0/00 20:00 1200 3.40E−71 3.31E−22 2.88E−05 47 60 1/0/0021:00 1260 8.29E−75 2.27E−23 1.39E−05 48 60 1/0/00 22:00 1320 2.02E−781.56E−24 6.72E−06 49 60 1/0/00 23:00 1380 4.94E−82 1.07E−25 3.25E−06 50360 1/1/00 0:00 1440 7.24E−85 4.43E−26 9.41E−06 51 360 1/1/00 6:00 18001.53E−106 4.66E−33 1.20E−07 52 360 1/1/00 12:00 2160 3.25E−128 4.91E−401.52E−09 53 360 1/1/00 18:00 2520 6.87E−150 5.17E−47 1.93E−11 54 14401/2/00 0:00 2880 5.82E−171 2.18E−53 9.84E−13 55 1440 1/3/00 0:00 43201.17E−257 2.68E−81 2.57E−20 56 1440 1/4/00 0:00 5760 — 3.30E−1096.72E−28

6.1.19.3 Additional Transactive Node Attributes where a Relaxation StopCriterion is Employed

Table 24 specifies four additional transactive node attributes that canbe used if a transactive node is to employ the relaxation stop criterionas it has been introduced in this appendix. These attributes can beassumed to be assignable at the transactive-node level. It isconceivable that this criterion (or another) and its attributes may inthe future be configured differently for each transactive neighborconnection.

TABLE 24 Dictionary of the Relaxation Stop Criterion Attributes that maybe Configured at a Transactive Node Range of No. Attribute NameDescription Role Type Format values C1 Relaxation This is one of ThisSingle real — Typically, [0, Stop Criterion the two parameter number.1). Proportionality parameters represents a This Default Threshold- thatdetermine maximum parameter's value: TIS whether a allowed units of0.0005. calculated average measure are Set to 0.0 Output TIS absoluteeffectively the for time series difference same as for maximum hasbetween the Output iterations. adequately consecutively TIS: $/kWh. Setto 1 to relaxed to a calculated practically steady Output TIS eliminatesolution at this members iterations transactive TIS_(n). altogether.node. The Empirically This magnitudes of set this parameter isattributes C1 parameter's the and C3 value to proportionality togetherachieve the constant K affect how desired that is shown similar Outputnumbers of in Eq. C4. TIS time Output TIS series should being be for usto transmitted stop iterating from this and again transactivetransmitting node. the Output TIS. The magnitude of this parameteraffects how many times an Output TIS will be sent to transactiveneighbors by this transactive node. C2 Relaxation This is one of ThisSingle real — Typically, [0, Stop Criterion the two parameter number.100,000). Proportionality parameters represents a This DefaultThreshold- that determine maximum parameter's value: 100. TFS whether aallowed units of Set to 0.0 calculated average measure are for OutputTFS absolute effectively the maximum time series difference same as foriterations. has between an Output Set to adequately consecutively TFS:Average 100,000 to relaxed to a calculated kW. practically steady OutputTFS eliminate solution at this members iterations transactive TFS_(n).altogether. node. The Empirically This magnitudes of set this parameteris attributes C2 parameter's the and C4 value to proportionalitytogether achieve the constant K affect how desired that is shown similarOutput numbers of in Eq. C4. TFS time Output TFS series should being befor us to transmitted stop iterating from this and again transactivetransmitting node. the Output TFS. The magnitude of this parameteraffects how many times an Output TFS will be sent to transactiveneighbors by this transactive node. C3 Relaxation This is one of ThisSingle real — Range: [1, Stop Criterion the two parameter number. 2).Gamma parameters represents This Default: 1.0 Parameter- that determinethe relative parameter is Empirically TIS whether a impact of adimensionless. set this calculated sample's parameter's Output TISduration and value to time series a sample's achieve the has distanceinto desired adequately the future as numbers of relaxed to a successiveOutput TIS steady Output TIS being solution at this values aretransmitted transactive being from this node. compared. transactive ThisThe node. parameter is magnitudes of the constant Y attributes C1 thatis shown and C3 in Eq. C4. together affect how similar Output TIS timeseries should be for us to stop iterating and again transmitting theOutput TIS. The magnitude of this parameter affects how many times anOutput TIS will be sent to transactive neighbors by this transactivenode. C4 Relaxation This is one of This Single real — Range: [1, StopCriterion the two parameter number. 2). Gamma parameters represents ThisDefault: 1.0 Parameter- that determine the relative parameter isEmpirically TFS whether a impact of a dimensionless. set this calculatedsample's parameter's Output TFS duration and value to time series asample's achieve the has distance into desired adequately the future asnumbers of relaxed to a successive Output TIS steady Output TFS beingsolution at this values are transmitted transactive being from thisnode. compared. transactive This The node. parameter is magnitudes ofthe constant Y attributes C2 that is shown and C4 in Eq. C4. togetheraffect how similar Output TIS time series should be for us to stopiterating and again transmitting the Output TIS. The magnitude of thisparameter affects how many times an Output TIS will be sent totransactive neighbors by this transactive node.

6.2 Appendix B—Transactive Node Toolkit Framework 6.2.1 Terms

This section will sometimes make reference to the following terms, whosenonlimiting definitions are also given below. These definitions do notnecessarily apply in all instances and may vary depending on thecontext.

elastic load Within the toolkit framework, the change in electrical loadthat is expected as responsive asset systems respond to the transactiveincentive signal (TIS). Within the toolkit framework, information aboutelastic load will be stored into and available from the Toolkit ResponseFunction Output Parameter Buffer. inelastic load Electrical load that isnot responsive to the transactive incentive signal (TIS) at atransactive node. In certain implementations, it is recommended thatinelastic load should also include the predicted load from responsiveasset systems if they were to not respond to the TIS. Within the toolkitframework, information about inelastic load will be stored into andavailable from the Inelastic Load Prediction Buffer. input transactiveinput A transactive feedback signal (TFS) that has been receivedfeedback signal TFS from a transactive neighbor as an input to the setof calculations that is to be conducted at a transactive node at theupdated frequency. input transactive input A transactive incentivesignal (TIS) that has been received from incentive signal TIS atransactive neighbor as in input to the set of calculations that is tobe conducted at a transactive node at the update frequency. intervalstart IST An attribute of transactive signals. The series of futuretimes time that define the starting times of members of set of futuretime intervals. The duration of each interval is defined by the timebetween two consecutive interval start times. other local OLC A broadset of information and data that will be inputs into the conditions manyfunctions and processes that is to be performed at transactive nodes.This set excludes transactive signals. output output A transactivefeedback signal (TFS) object output from the transactive TFScalculations that are to be conducted at a transactive node at feedbacksignal the update interval. A transactive node prepares an output TFSthat predicts the average power to be exchanged with a transactiveneighbor into the future. output output A transactive incentive signal(TIS) object output from the transactive TIS calculations that are to beconducted at a transactive node at incentive signal the update interval.responsive asset A system within the control of a transactive node thatwill system change its consumption or generation in response to thetransactive node's transactive incentive signal (TIS) and other localconditions. toolkit The toolkit framework, toolkit function libraries,the set of toolkit functions, and/or associated documentation. toolkitThe general functionality and responsibilities at any transactiveframework node. The flow in which high-level and more specific toolkitfunctions are coordinated and accomplished. toolkit function Anindividual functional capability that may be implemented at atransactive node. There are two main types of toolkitfunctions-incentive and response. toolkit function A set of toolkitfunctions available to implementers. library Implementers select toolkitfunctions from this library that can be instantiated and interoperablyapplied at their transactive node. toolkit load A toolkit functioninserted into the toolkit framework process function 8. CalculateToolkit Resource and Incentive Function that calculates energy andenergy cost for a resource and other cost components and incentives thatwill be used in the formulation of the transactive incentive signal.toolkit resource A toolkit function inserted into the toolkit frameworkprocess and incentive 6. Calculate Toolkit Load Function that calculatesthe function predicted inelastic load and changes in elastic loadcomponents of the entire load at a transactive node. transactive TC Anegotiated form of power grid control that uses price-like controlincentive and feedback signals. transactive TCS A distributed systemthat employs transactive control and control and coordination.coordination system transactive TFS One of the major transactive signalsemployed by feedback signal embodiments of a transactive control andcoordination system. A transactive node's reporting of the expectedaverage power to be transferred between two transactive neighbors duringintervals over the next several days. transactive TIS One of the majortransactive signals employed by incentive signal embodiments of atransactive control and coordination system. A transactive node'sreporting of the anticipated delivered cost of electrical power at itslocation at intervals over the next several days. transactive TS Eitherthe transactive incentive signal (TIS) or transactive signal feedbacksignal (TFS). transactive Transactive nodes that exchange electricalenergy between neighbors them and therefore also exchange transactivesignals. transactive node TN A defined location of the transactivecontrol and coordination system that has agreed to exchange transactiveincentive signals (TIS) and transactive feedback signals (TFS) with itstransactive neighbors. transactive node TNMA A module of software wherethe functionality of transactive model algorithm control is created fora transactive node. The Demonstration chooses to apply this term tosoftware modules that serve this function. transactive node A formalconstruct possessing attributes that may be used to object define thestate of a transactive node and the transition between those states.Transactive TNOM The model of the states of the transactive node objectand the node object functions by which it moves from one state toanother. The model TNOM includes the model of a transactive nodeobject's configuration. update Reciprocal of the update interval. Theupdate frequency should frequency be made configurable to support futureimplementations and testing. update interval Relatively short timeinterval between consecutive updates of the TIS and TFS at eachtransactive node.

6.2.2 Introduction

A transactive node represents a predetermined component or region withinan electric power grid at which electrical energy may be generated,consumed, imported, or exported. In principle, the transactive nodeconstruct will be scalable and similarly applicable to from small,end-use equipment (e.g., a distribution transformer, residentialthermostats) to large regions (e.g., the boundary of an electricutility). A transactive node includes an agent of sorts (e.g., acomputer and its software applications) that orchestrates eachtransactive node's responsibilities to:

1. economically balance energy

2. incentivize energy consumption or generation

3. activate its own responsive generation and load resources

4. exchange both transactive incentive signals (TIS) and transactivefeedback signals (TFS) with each of its neighboring transactive nodes.

The two transactive signals—the transactive incentive signal (TIS) andtransactive feedback signal (TFS)—reveal the predicted local deliveredcost of electric energy and the predicted use of a TN to exchangeelectrical energy with its neighbors, given the value of the TIS andother predicted local conditions. (While this document refers often topairs of TIS and TFS signals, the two signals need not necessarilyalways be received and sent together and simultaneously. Instead, thesignals can be decoupled so that they may be sent and receivedseparately.)

These functional behaviors should be designed into the transactivecontrol and coordination system. Depending on its complexity,memberships, and location in its power grid, a transactive node mayassume all, some, or practically none of the responsibilities to bedescribed in this document. The toolkit function library construct isone way to organize and teach the responsibilities of a TN to those whowould wish to define a transactive node and have their transactive nodeenter into an existing transactive control and coordination system. Thetoolkit library should not only hasten the adoption and implementationof transactive control, but it should also standardize implementationsof transactive control so that the building blocks components will bemore interoperable. The toolkit library should be available toimplementers who may choose from and learn from others' experiences andpractices. The template for toolkit library functions anticipatesproviding reference implementation code with which implementers may jumpstart their instantiation of similar functions.

The functional responsibilities of a transactive node will be describedat two levels of the toolkit:

1. Toolkit framework—the high-level computational structure thatprovides basic transactive control functionality of transactive nodesand that calls upon specific toolkit library functions to enact thefunctionality of specific incentives and assets.

2. Toolkit library functions—the specific functions that account forresource, enact incentives and plan asset responses at transactive nodeswhere these specific functions have been implemented and are relevant.Applicable toolkit library functions are called upon and acted uponwithin the toolkit framework.

6.2.3 Toolkit Framework

The toolkit framework is a high-level structure for the inputs,functions, processes, and outputs that define transactive controlfunctionality at a transactive node. The toolkit framework will probablybe found to encompass the high-level functional responsibilities of thetransactive node model algorithm (TNMA) module.

(This document primarily addresses the algorithmic functionality of atransactive node and its responsibilities toward management ofelectrical energy. This document may facilitate, but does not intend tospecify, functionality toward system management, timing, and datacollection that are better addressed within the transactive node'sobject model.)

FIG. 35 is a flowchart 3500 that shows the flow of information duringeach update interval (e.g., 5-minute update interval) at the rate of theupdate frequency. This is a functional flow, not necessarily arecommendation for how a developer will construct the software program.The blocks in this diagram represent functions and processes. Thedistinction between “functions” and “processes” may be somewhatsubjective, but a process will have been defined to have multiplesub-functions and/or sub-processes. Blocks of FIG. 35 shown with boldoutlines are processes, known to be composed of at least twosub-functions or processes.

The flow of information in FIG. 35 is indicated by solid arrows.Information is processed predominantly downward through the diagram,which makes the diagram useful for understanding functional, sequentialinterdependencies. Other logical flow control and dependencies are shownby dashed arrows.

Information buffers appear in several of the information flow paths.These buffers are available to be mined by data collection processes andmight be made accessible to the system management level. (These buffers,if defined as part of a standard transactive node definition, can beused as a point of observability for testing. In addition, the option ofpreloading the buffers may be useful for testing (especially if only the5-minute update frequency is available).) The buffers also providerecent information that may be used if any prior function or processshould fail to promptly complete its responsibilities or provide itsoutput information. The flow in this diagram has been greatly simplifiedby the assumption that any buffered historical information is availableto be used by any other function or process at this transactive node.

As part of its data collection design for transactive data, a number ofbuffers can be used. For example, in the illustrated embodiment in FIG.35, five buffers are identified, the contents of which compose asufficient snapshot of the calculations that have been completed by thetoolkit framework and its toolkit functions at a transactive node. Thefive buffers are those into which calculation products are to be sent:Resource Schedule and Cost Buffer, Output TIS Buffer, Output TFS Buffer,Inelastic Load Prediction Buffer, and Elastic Load Prediction Buffer.The freshest, unique buffer records from these five buffers arespecified to be collected after any transactive signal has beencalculated and sent to a transactive neighbor. The sampling of thesefive buffers is sufficient in the sense that the outputs from eachtoolkit resource and incentive function and each toolkit load functionare revealed, the TIS and TFS transactive signals that have beentransmitted from this transactive node are revealed, and the magnitudesof transactive signals that have been received may be inferred, if notperfectly known. Alternatively, signal timing and data collection can beinitiated by changes that have been detected, not by rigid timers.

The following processes and functions are referenced in FIG. 35 and willbe described in the next sections. Defined functions, processes, andspecially defined inputs and outputs of the functions and processes willbe shown in bold font in this document.

1. Receive Transactive Signals

1.1. Read TIS and TFS from Transactive neighbor

1.2. Check Authentication and Security

1.2.1. Interact with System Management (Security)

1.3. Check Validity of Transactive Signals

1.3.1. Interact with System Management (Validity)

1.4. Update Input Transactive Signal Buffer for this Transactiveneighbor

2. Calculate New Transactive Signal Intervals

2.1. Read Present Time

2.2. Calculate First Interval Start Time IST₀

2.3. Calculate 5-Minute Interval Start Times

2.4. Calculate 15-Minute Interval Start Times

2.5. Calculate 1-Hour Interval Start Times

2.6. Calculate 6-Hour Interval Start Times

2.7. Calculate 1-Day Interval Start Times

2.8. Calculate Interval Durations from Interval Start Times

3. Formulate TIS

3.1. Refresh Default Output TIS

3.2. Calculate Total Costs of Non-Transactive Energy Generation andImports

3.3. Calculate Total Cost of Energy Imported from Transactive nodes

3.4. Calculate Total Capacity Cost/Incentives

3.5. Calculate Total Infrastructure Cost/Incentive

3.6. Calculate Total Other Cost/Incentive

3.7. Calculate Output TIS

3.8. Calibrate/Normalize TIS

3.9. Interpolate Intervals Service Functions

4. Formulate TFS

4.1. Interpolate Intervals Service Functions

4.2. Predict Net Resource Surplus or Shortage

4.3. Disaggregate Net Resource Surplus or Shortage

4.4. Refresh Default Output TFS

5. Sum Total Predicted Load

5.1. Interpolate Intervals Service Functions

5.2. Sum Inelastic Load

5.3. Sum Change in Elastic Load

5.4. Sum Total Inelastic and Change in Elastic Load

5.5. Refresh Predicted Total Inelastic and Elastic Load

6. Calculate Applicable Toolkit Load Functions

6.1. Interpolate Intervals Service Functions

6.2m Toolkit Load Function

6.3 Refresh Predicted Inelastic and Elastic Loads

7. Send Transactive Signals (Defined only functionally at a high level)

8. Calculate Applicable Toolkit Resource and Incentive Functions

9. Control Responsive Asset Systems (Defined only functionally at a highlevel)

10. Sum Total Predicted Resources

10.1. Interpolate Intervals Service Functions

10.2. Sum Total Predicted Resource

10.3. Refresh Predicted Total Resource

11. Control Responsive Resource

The next sections will describe examples of the functions in the abovelist. The sections below are demarcated by the function numbers setforth in the list above, and are not to be confused with the sectionnumbering used outside of this appendix.

1. Receive Transactive Signals

Purpose:—

Transactive signals are signals to be communicated between transactivenodes in a transactive control and coordination system. It is throughtransactive signals that transactive nodes share their temporal andlocational costs and thirsts for electrical energy. Transactiveincentive signals (TIS) and transactive feedback signals (TFS) should bereceived from the transactive node neighbors at the update frequency,which happens to be once every 5 minutes for the Demonstration.

This function includes technical validation of received signals toensure that they were properly formed and that their values are withinacceptable norms. Validation is not yet a high priority, and validationprocesses probably do not need to be standardized across all transactivenodes. If an invalid signal is detected, it should be flagged.Additional actions may be taken to notify or alert targeted systemoperators and reduce the impacts from potentially misleading signals.

Applicability:

This function should be completed by a transactive node at least onceduring an update interval. If this function fails, functions andprocesses of the toolkit framework that use an input transactive signalshould revert to buffered historical signals.

Sub-Functions and Sub-Processes:

The following sub-functions are iteratively completed until the inputtransactive signals from transactive neighbors have been received.

1.1 Read TIS and TFS from a Transactive neighbor—Function by which theTIS and TFS from a transactive neighbor is to be received. Mostgenerally, the implementation details by which this sub-function is tobe accomplished should be negotiated by pairs of transactive neighborsthat will exchange transactive signals.

1.2 Check Authentication and Security—Functional block (or blocks) forsignals like transactive signals that are to be conveyed through thetransactive control and coordination system. The actual functionalimplementation details for security functions may differ from oneimplementation to another, but general descriptions for this blockshould be documented if they are applicable to any transactive node.

1.2.1 Interact with System Management (Security)—Actions that are to betaken if Check Authentication and Security function fails toauthenticate a transactive signal or detects an insecurity. The inputtransactive signals are terminated if they cannot be authenticated or ifsecurity violations are suspected. Actions may include notifications andalerts that are to be conveyed by the system management layer. Specificactions of this function may differ by implementation.

1.3 Check Validity of Transactive Signals—Functional block (or blocks)by which the structure or contents of a transactive signal may be testedagainst expected and reasonable structure and content. Examples ofchecks on the structure of the signals could include verification ofadherence to an XML schema, an expected number of future intervals, orthe ordering of a series within the signal. An example of a contentcheck would be verification that a signal's values are between statedmaximum and minimum values.

1.3.1 Interact with System Management (Validity)—Actions that are to betaken if the Check Validity function fails validate transactive signals.The input transactive signals are terminated and not used or stored ifthey cannot be validated. Actions may include notifications and alertsthat are to be conveyed by the system management layer. Specific actionsof this function may differ by implementation. General functionalaspects for this function that should apply to transactive nodes shouldbe documented and implemented. More sophisticated actions may be taken,including reducing the Quality attribute of signals that havequestionable validity.

1.4 Update Input Transactive Signal Buffer for this Transactiveneighbor—Received transactive signals are saved into the InputTransactive Signal Buffer. The buffer may be as simple as a running (orcircular) list of transactive signal pairs that have been received fromtransactive neighbors. The most recently received pairs or transactivesignals from each transactive neighbor are most relevant within thisbuffered data. A much longer buffered history may be used at transactivenodes that use trending to predict transactive neighbors' responses(e.g., elasticity) or to improve the accuracy of their transactivesignal predictions over time.

Inputs:

-   -   Input TIS from a transactive neighbor    -   Input TFS from a transactive neighbor    -   List of transactive neighbors from which transactive signals are        expected to be received as should be known by the transactive        node object and available from the Node State and Status Buffer.        This information in the Node State and Status Buffer can be part        of the transactive node configuration and state available within        the transactive node object model, not temporary “buffer”        information as the name might imply.

Outputs:

-   -   Buffered copies of Input TIS and TFS.    -   Copies of Input TIS and TFS pairs conveyed to a data archive by        the data collection system layer.    -   System management notifications and alerts upon failed security        or validation checks, if such system management functions have        been defined and if this transactive node is obligated to        interact with a system manager.

Dependencies:

-   -   Outputs of this function are used by Resource Schedules and Cost        Buffer.    -   Outputs of this function are used by Formulate TIS.    -   Times at which this transactive node is eligible to receive        transactive signals may be managed or limited by the current        state of the transactive node object, which status is assumed to        be known and available from a Node State and Status Buffer.    -   A set of transactive neighbors should be available from        attributes of the transactive node object, which are assumed to        be known and available from a Node State and Status Buffer.

Notes:

-   -   The TIS and TFS are state objects of the Project-Level        Infrastructure (PLI) transactive control and coordination        system. This process expects and checks that transactive signals        are being received with the specified content and structure,        which may be further enforced through the use of, for example,        accepted XML schema.    -   Considerable tolerance should be built into this function to        coordinate with neighboring transactive nodes and their        readiness to release their transactive signals. The function        should be tolerant for when transactive signals are not        received, or are not received early enough to influence the        present update iteration.    -   When an incomplete set of transactive signals is received by a        transactive node, the transactive node should rely upon buffered        historical information from previous iterations. Unless the        power grid's predicted future has changed dramatically, the        buffered signals will remain good predictions until input        transactive signals are received.    -   A Node State and Status Buffer has been established within the        toolkit framework to ensure that it has information it may used        concerning timing, transactive neighbors, and other status        information concerning activities of the transactive node        object.    -   This function interacts with cyber security subsystems. It is        assumed here that authentication and other cyber-security tests        have been conducted during signal transport or upon signal        receipt.    -   This function potentially interacts with system management if        invalid signals are detected or if notifications or alerts        should be conveyed through the system for any reason concerning        signals that have been, or should have been, received.    -   This function potentially depends upon assumptions and        functionality within the state transition diagrams of the        transactive node state, which design is presently incomplete. It        has been assumed that the transactive node state diagram has        provided states where toolkit framework functionality may (or        may not) be conducted. Otherwise, it has been assumed that that        design of the transactive node state transitions does not        encroach on the functional responsibilities of the toolkit        framework.

FIG. 36 is a flowchart 3600 illustrating an exemplary receivetransactive incentive signal process.

2. Calculate New Transactive Signal Intervals

Purpose:

Calculate the new interval start time (IST) time series that areattributes of the two transactive signal object types that are to beformulated and conveyed throughout the transactive control andcoordination system. See SubAppendix A: Interval Start Time SeriesDefinition for details about an example IST time series and how theseries is calculated.

Applicability:

This function should be completed by transactive nodes at the updatefrequency. In particular implementations, an update frequency of onceevery 5 minutes is used, though other intervals can be used.

Sub-Functions and Sub-Processes:

The sub-function steps will be described along with this introduction tothe sub-functions. Refer to SubAppendix A for additional details andexamples.

2.1 Read Present Time—the present time is locally maintained at eachtransactive node and should be read near the beginning of eachiteration. The present time and representations of time are to bemaintained using the UTS standard.

2.2 Calculate First Interval Start Time IST₀—to calculate IST₀, roundthe present time up to the nearest 5-minute interval.

2.3 Calculate 5-Minute Intervals Start Times—to calculate IST₂ throughIST₁₁, add 5 minutes to the prior IST.

2.4 Calculate 15-Minute Interval Start Times—to calculate IST₁₂, add 15minutes to the prior IST₁₁, and round down to a 15-minute interval. Tocalculate the remaining 15-minute intervals IST₁₃ through IST₃₁, add 15minutes to the prior IST.

2.5 Calculate 1-Hour Interval Start Times—to calculate IST₃₂, add 1 hourto the prior IST₃₁, and round down to a 1-hour interval. To calculatethe remaining 1-hour intervals IST₃₃ through IST₄₉, add 1 hour to theprior IST.

2.6 Calculate 6-Hour Interval Start Times—to calculate IST₅₀, add 6hours to the prior IST₄₉, and round down to a 6-hour interval. Tocalculate the remaining 6-hour intervals IST₅₁ through IST₅₃, add 6hours to the prior IST.

2.7 Calculate 1-Day Interval Start Times—to calculate IST₅₄, add 1 dayto the prior IST₅₃, and round down to a 1-day interval. To calculate theremaining 1-day interval IST₅₅, add 1 day to the prior IST₅₄. In certainembodiments, a final IST₅₆ can be appended that will unambiguouslydefine the duration of the final interval. (The final IST does notdefine a new interval, it simply states the end of the last interval.)

2.8 Calculate Interval Durations from Interval Start Times—the functionby which IST interval durations may be discerned from an IST time seriesis as follows:

2.8.1 Calculate Δt₀—Subtract IST₁—IST₀ to learn the duration of intervalΔt₀ that starts at IST₀.

2.8.2 Tentatively Assign Remaining Δt_(n)—successively subtractIST_(n)−IST_(n−1) to tentatively assign durations Δt_(n). The durationof Δt₅₅ has been made unambiguous by appending IST₅₆, which is the endof the last interval.

2.8.3 Perform Checks—certain checks may be possible on the structure ofthe tentative set of IST intervals. In this formulation, both the ISTtimes and interval durations should increase or stay the same as oneprogresses through the series. The tentative set of intervals should becorrected if it does not pass these local checks. The system managementlayer may be employed to flag, alert, or announce failed checks, but itis the each local node's responsibility alone to produce and use acorrect and accurate set of IST intervals.

Inputs:

-   -   Present time (determines the first interval start time IST₀ for        the new output transactive signals)

Outputs:

-   -   IST time series—Series of interval start times {IST₀, IST₁, . .        . , IST_(N)} to be used in output TIS and output TFS stored into        and available from the Current IST Series Buffer    -   Series of IST interval durations {Δt₀, Δt₁, . . . , Δt_(N)} that        correspond to the N+1 members of the IST series stored into and        available from the Current IST Series Buffer.

Function/Process:

The process steps were described above as the sub-functions were beingintroduced. Refer to SubAppendix A for further details, pseudo code, andexamples.

Dependencies:

-   -   The function's output is used by process 3. Formulate TIS    -   The function's output is used by process 4. Formulate TFS

Notes:

-   -   The need for synchronicity is low or does not exist in a        transactive control and coordination system. Therefore, local        time should be accurate only to within several tens of seconds.        This goal should not be particularly challenging to meet.        Regardless, the Demonstration has imposed requirements for and        means to achieve impressive synchronicity across its system.    -   The IST series is an attribute of both the TIS and TFS state        objects.    -   While the current interval start time (IST) time and interval        series are most relevant to the formulation of transactive        signals, many toolkit framework and toolkit library functions        use access to the current IST time and interval series. The        Current IST Series Buffer construct was created to make this        accessibility explicit within the toolkit framework.

FIG. 37 is a flowchart 3700 for an exemplary calculate new transactivesignal intervals process.

3. Formulate TIS

Purpose:

Process by which the TIS, one of the two transactive signals, is to beformulated at a transactive node. From its predecessors, this processreceives parametric information that is used to determine how energy,capacity, infrastructure, and other influences are to be valued duringformulation of the output TIS at this transactive node.

Applicability:

This process should be completed at the update frequency by transactivenodes. Some of the sub-functions and sub-processes within this processmay be trivial or empty at transactive nodes where the sub-functions orsub-processes are not needed.

Sub-Functions and Sub-Processes:

3.1 Refresh Default Output TIS—simply retrieve the most recent outputTIS from the Output TIS Buffer at this transactive node and refresh itstime intervals by submitting it to function 3.10 Interpolate IntervalsService Functions. The resulting output TIS then returned to the OutputTIS Buffer to be used by default if for any reason this transactive nodedoes not compute a more current output TIS by the time it is used. Thissub-function should be completed early during each duration. Thispotentially creates a race condition in software unless the updatestatus of the buffer is maintained. Thus, in some embodiments, thisshould be used as a default value

3.2 Calculate Total Cost of Non-transactive Energy Generation andImports—for each IST interval, sum the cost of imported and generatedenergy from sources that are not transactive neighbors at thistransactive node. Examples include the costs of energy that is importedinto the region from Canada, California, or other entities that are notparticipating in transactive control. Another example would be bulkgeneration from a gas generator that is dispatched in ways that are notaffected by the region's transactive control and coordination system.The data that feed into this function will come from resource schedulesand Incentive Toolkit Functions that are employed at this transactivenode. This function becomes trivial and should not be used attransactive nodes that have neither non-transactive imports nor bulkgeneration.

The output from this function is the sum of products of pairs of energycosts C_(E,a,n) (units: cost per energy) and average generated orimported power {circumflex over (P)}_(G,a,n) (units: average power),weighted by the corresponding IST interval duration Δt_(n) (units:time).

$\begin{matrix}{\sum\limits_{a = 1}^{A}\;{{C_{E,a,n} \cdot {\hat{P}}_{G,a,n} \cdot \Delta}\; t_{n}}} & ( {{Sub}\text{-}{Function}\mspace{11mu} 3.2} )\end{matrix}$

3.3 Calculate Total Cost of Energy Imported from Transactive nodes—foreach IST interval, sum the cost of energy that is predicted to beimported from transactive neighbors. At times when energy is to beimported from transactive neighbors, the TIS & TFS from thosetransactive neighbors should be treated as special cases of importedenergy and treated similarly to non-transactive imported energy (e.g.,they result in (C_(E), P_(G)) pairs). The cost of energy from atransactive neighbor is that neighbor's TIS. The predicted energy to beimported from that neighbor is the neighbor's TFS at the boundarybetween that and this transactive node. Exported energy to transactiveneighbors should be disregarded in the calculation of the TIS. (In someembodiments, information about exported energy is found in the ResourceSchedules and Cost Buffer. In such embodiments, Functions 3.2 and 3.3can filter the buffer contents to address only imported energy, in whichcase the Resource Schedules and Cost Buffer is a complete rich source ofinformation for data collection concerning the outputs of ToolkitResource and Incentive Functions that are being employed at thistransactive node.) It is conceivable that a transactive node couldimport no energy from its transactive neighbors, but the TFS shared withthe neighbors should be checked nonetheless. (The prediction of energyto be exchanged to or from a transactive neighbor can be predicted byboth neighbors, by one of the neighbors, or some other combination.)

As for sub-function 3.2, the output from this function will continue thesum of products of pairs of energy costs C_(E,a,n) (TIS) (units: costper energy) and average generated or imported power {circumflex over(P)}_(G,a,n) (TFS) (units: average power), weighted by the correspondingIST interval duration Δt_(n) (units: time).

$\begin{matrix}{\sum\limits_{a = 1}^{A}\;{{C_{E,a,n} \cdot {\hat{P}}_{G,a,n} \cdot \Delta}\; t_{n}}} & ( {{Sub}\text{-}{Function}\mspace{11mu} 3.3} )\end{matrix}$

3.4 Calculate Total Capacity Cost/Incentive—for each IST interval, sumthe costs that are functions of a capacity. Constraints and demandcharges are examples. These are expected to be very non-linear, but theywill nonetheless be represented by a capacity cost and the capacity towhich they apply. This function may be trivial or empty at transactivenodes where no capacity costs or incentives are to be included in theoutput TIS.

The output from this sub-function is the sum of products of pairs ofcapacity costs C_(C,b,n) (units: cost per power capacity) and averagepower capacity {circumflex over (P)}_(C,b,n) (units: average power) foreach respective IST interval n.

$\begin{matrix}{\sum\limits_{b = 1}^{B}\;{C_{C,b,n} \cdot {\hat{P}}_{C,b,n}}} & ( {{Sub}\text{-}{Function}\mspace{11mu} 3.4} )\end{matrix}$

3.5 Calculate Total Infrastructure Cost/Incentive—for each IST interval,sum the infrastructure (e.g., time-based) costs that should be appliedduring the interval. This function may be trivial or empty attransactive nodes where no infrastructure costs or incentives are to beincluded in the output TIS.

The output from this sub-function is the sum of products of pairs ofinfrastructure costs C_(I,c,n) (units: cost per time) and the respectiveinterval duration Δt_(n) (units: time).

$\begin{matrix}{\sum\limits_{c = 1}^{C}\;{{C_{I,c,n} \cdot \Delta}\; t_{n}}} & ( {{Sub}\text{-}{Function}\mspace{11mu} 3.5} )\end{matrix}$

3.6 Calculate Total Other Cost/Incentive—for each IST interval, sumthose influences that cannot be described by the energy, capacity, andinfrastructure functions. (Other Cost/Incentive functions are desirablyused infrequently for influences that cannot be described with the otherfunctions. The representation of cost by this function should still be adefensible cost of delivered energy and will be subject to comparisonagainst other cost accountings over relatively long time periods.) Thisfunction may be trivial or empty at transactive nodes where no othercosts or incentives are to be included in the Output TIS.

The output from this sub-function is the sum of “Other” costs C_(O,d,n)(units: cost).

$\begin{matrix}{\sum\limits_{d = 1}^{D}\; C_{O,d,n}} & ( {{Sub}\text{-}{Function}\mspace{11mu} 3.6} )\end{matrix}$

3.7 Calculate Output TIS—a simple parametric function that combinesoutputs from above functions to complete calculation of the Output TISfor this transactive node. The sums completed by five othersub-functions appear in this sub-function. Details about this functionare expanded upon in the Section 3.7 Details about the Calculate OutputTIS Function.

$\begin{matrix}{{TIS}_{n} = \frac{\begin{matrix}{{\sum\limits_{a = 1}^{A}\;{{C_{E,a,n} \cdot {\hat{P}}_{G,a,n} \cdot \Delta}\; t_{n}}} +} \\{{\sum\limits_{b = 1}^{B}\;{C_{C,b,n} \cdot {\hat{P}}_{C,b,n}}} + {\sum\limits_{c = 1}^{C}\;{{C_{I,c,n} \cdot \Delta}\; t_{n}}} + {\sum\limits_{d = 1}^{D}\; C_{O,d,n}}}\end{matrix}}{\sum\limits_{a = 1}^{A}\;{{{\hat{P}}_{G,a,n} \cdot \Delta}\; t_{n}}}} & ( {{Sub}\text{-}{Function}\mspace{11mu} 3.7} )\end{matrix}$

3.8 Calibrate/Normalize TIS—algorithm by which the output TIS are to becompared against and perhaps made to track other cost accountingmethods. If the calculation of a TIS is meaningful as the delivered costof electrical energy, it should track other reasonable accountings ofthe delivered cost of electrical energy over relatively long periods oftime. In some embodiments, this is a general requirement on the TIS.This general requirement may be enforced by a bias input that will forcethe TIS to track other less dynamic accountings and thereby correct theTIS.

3.9 Interpolate Intervals Service Functions—parse energy and costs fromcoarse intervals into multiple sub-intervals. This function is necessarybecause the set of IST intervals to be used by the output TIS will havedivided some prior intervals into sub-intervals. This function is aservice function that is called as often as it is desired. The objectsTIS and TFS may simply be replicated for each sub-interval. (While manycomplex methods may evolve to interpolate and assign costs and averagepower to sub-intervals, in certain embodiments of the disclosedtechnology, the cost and average power from an interval are assigned toits sub-intervals.)

Inputs:

-   -   Energy cost, scheduled/committed non-transactive energy pairings        for each non-transactive generation or import resource at a time        interval        (IST*_(n) ,Δt* _(n),(C _(E,1,n) ,{circumflex over (P)}        _(G,1,n)),(C _(E,2,n) ,{circumflex over (P)} _(G,2,n)), . . .        ,(C _(E,a,n) ,{circumflex over (P)} _(G,a,n)), . . . ,(C        _(E,A,n) ,{circumflex over (P)} _(G,A,n))),        where n is a time interval of the TIS numbered from 0 to 55;        IST_(n) is interval start time n in a series of interval start        times; Δt_(n) is the duration of interval n; C_(E,a,n) is the        energy cost term (e.g., units $/kWh, like the TIS) of the        scheduled generation or import resource a for IST interval n,        and {circumflex over (P)}_(G,a,n) is the average generated or        imported power from generation or import resource a during time        interval n. Its units are the same as for TFS (e.g., average        power). (The asterisk indicates that this series of Interval        Start Times and durations will likely differ from those that        have been calculated to be used with the Output TIS and Output        TFS. The function 3.10 Interpolate Intervals Service will sort        this out for the inputs into the other sub-functions. See, e.g.,        Figure C-4.)    -   Input TIS and input TFS pairings from each transactive node        neighbor for each time interval        (IST*_(n) ,Δt* _(n),(TIS_(1,n),TFS_(1,n)),(TIS_(2,n),TFS_(2,n)),        . . . ,(TIS_(j,n),TFS_(j,n)), . . . ,(TIS_(J,n),TFS_(J,n))),        where TIS_(j,n) and TFS_(j,n) are the input transactive signals        from transactive node neighbor j during time interval n. This        input should be considered a special case of the input described        in the preceding bullet. (At times that energy is predicted to        be imported from a transactive neighbor, the corresponding TIS        and TFS are special cases of C_(E,a,n) and P_(G,a,n) and will be        treated very much the same.)    -   Interval start time series        {IST₀,IST₁, . . . ,IST_(N)}        and interval duration series        {Δt ₀ ,Δt ₁ , . . . ,Δt _(N)}        to be used for Output TIS and Output TFS. (These notations do        not have asterisks because they are final intervals to be used        in the output transactive signals after this iteration.) In FIG.        4, the Interval Start Time Series is shown as an input to the        function 3.10 Interpolate Intervals Service, which have the        responsibility to resolve any discrepancies between various        representations of intervals.    -   Energy term(s) C_(E) from applicable incentive toolkit        functions, if any. (Energy terms C_(E) have the same usage and        interpretation regardless of whether they are used inside or        outside a Toolkit Incentive Function. This term accounts for        costs that are roughly proportional to an amount of energy that        is being generated or imported into a transactive node's        boundary.) The format should be identical to that stated above        for non-transactive energy pairings.    -   Average Power terms(s) {circumflex over (P)}_(G) from applicable        incentive toolkit functions, if any. (The average power terms        are used similarly regardless of whether they are used in or        outside a Toolkit Incentive Function. These terms are an        accounting of the average power that is either generated within        our imported into a transactive node boundary.) The format        should be identical to that stated above for non-transactive        energy pairings.    -   Capacity term(s) C_(C) from applicable Incentive toolkit        functions, if any, applicable at each IST interval        (IST*_(n) ,Δt* _(n),(C _(C,1,n) ,{circumflex over (P)}        _(C,1,n)),(C _(C,2,n) ,{circumflex over (P)} _(C,2,n)), . . .        ,(C _(C,b,n) ,{circumflex over (P)} _(C,b,n)), . . . ,(C        _(C,B,n) ,{circumflex over (P)} _(C,B,n))),        where C_(C,b,n) is the cost to be applied to capacity cost item        b paired with the capacity {circumflex over (P)}_(C,b,n) to        which it applies, and {circumflex over (P)}_(C,b,n) is the        average power capacity for capacity cost item b to be multiplied        by capacity cost C_(C,b,n) for IST interval n.    -   Infrastructure term(s) C_(I) from applicable incentive toolkit        functions, if any        (IST*_(n) ,Δt* _(n) ,C _(I,1,n) ,C _(I,2,n) , . . . ,C _(I,c,n)        , . . . ,C _(I,C,n)),        where C_(I,c,n) is the infrastructure term c for the IST        interval n.    -   Other term(s) C_(O) from applicable Incentive toolkit functions,        if any, for each IST interval        (IST*_(n) ,Δt* _(n) ,C _(O,1,n) ,C _(O,2,n) , . . . ,C _(O,d,n)        , . . . ,C _(I,D,n)),        where C_(O,d,n) is the “Other” influence term d for IST interval        n.    -   Exemplary alternative cost accounting(s) for use by function 3.9        Calibrate/Normalize TIS. Examples include wholesale energy costs        for the same energy or utility expenses.

Interim Calculation Products:

-   -   Total Cost of Non-transactive Energy Imports    -   Total Cost of Non-transactive Energy Generation    -   Total Cost of Energy Imported from Transactive neighbors    -   Total Capacity Cost/Incentive    -   Total Infrastructure Cost/Incentive    -   Total Other Cost/Incentive    -   Total Cost    -   Total Energy Imported or Generated    -   Additionally, interim calculations may be used to represent        prior interval information in terms of the new IST time series        and interval durations that are to be used by the Output TIS.

Outputs:

-   -   New “Updated” Output TIS at this transactive node.

Function/Process:

Each of the sub-functions/sub-processes should be defined, butsub-function 3.8 Calculate Output TIS defines the parametric calculationof the output TIS from the energy, capacity, infrastructure, and otherparameters and how the parameters are to be applied. The implementer whounderstands sub-function 3.8 Calculate Output TIS will have the insightto formulate toolkit functions and will have considerable flexibility inthe way such toolkit functions are formulated.

Dependencies:

-   -   Uses input of new IST time series from process 2. Calculate New        Transactive Signal Intervals    -   Uses input of TIS and TFS from at least one transactive neighbor        via process 1. Receive Transactive Signals    -   Process inputs may come from Calculate Applicable Toolkit        Incentive Functions    -   Process inputs may come from Resource Schedules and Cost Buffer.    -   Output TIS from this process is used by process 7. Send        Transactive Signals.    -   Output TIS from this process may be used by Calculate Applicable        Toolkit Response Functions dP(TIS,OLC) if this transactive node        owns responsive assets.

Notes:

-   -   Each transactive node produces one and only one TIS for itself        for each 5-minute update iteration.    -   The TIS itself is a time series that expresses the delivered        cost of energy into the future about 3 days, or so, as is        defined by the IST time series.

FIG. 38 is a flowchart 3800 illustrating an exemplary formulate TISprocess.

Details about the Function 3.7 Calculate Output TIS

Purpose:

Describes the final parametric calculation of the output TIS. Thissub-function consists of a simply stated function of the sum products ofother sub-functions 3.2 through 3.7. This sub-function creates a levelof standardization that will help ensure that the TIS at distributedpoints in a transactive control and coordination system are defensiblerepresentations of the “delivered cost of energy.”

Applicability:

A sub-function of 3. Formulate TIS Process that should be calculated atthe update frequency at transactive nodes.

Sub-Functions and Sub-Processes:

None. This is a simple arithmetic function of sums that have beencalculated by sub-functions 3.2 through 3.7.

Inputs:

-   -   Summed cost of energy terms

$\begin{matrix}{\sum\limits_{a = 1}^{A}\;{{C_{E,a,n} \cdot {\hat{P}}_{G,a,n} \cdot \Delta}\; t_{n}}} & ( {{Sub}\text{-}{Function}\mspace{11mu} 3.2\mspace{11mu}{and}\; 3.3} )\end{matrix}$from sub-functions 3.2 Calculate Total Cost of Non-Transactive EnergyGeneration and Imports and 3.3 Calculate Total Cost of Energy Importedfrom Transactive nodes

-   -   Summed cost of capacity terms

$\begin{matrix}{\sum\limits_{b = 1}^{B}\;{C_{C,b,n} \cdot {\hat{P}}_{C,b,n}}} & ( {{Sub}\text{-}{Function}\mspace{11mu} 3.4} )\end{matrix}$from sub-function 3.4 Calculate Total Capacity Cost/Incentive

-   -   Summed cost of infrastructure terms

$\begin{matrix}{\sum\limits_{c = 1}^{C}\;{{C_{I,c,n} \cdot \Delta}\; t_{n}}} & ( {{Sub}\text{-}{Function}\mspace{11mu} 3.5} )\end{matrix}$from sub-function 3.5 Calculate Total Infrastructure Cost/Incentive

-   -   Summed other costs

$\begin{matrix}{\sum\limits_{d = 1}^{D}\; C_{O,d,n}} & ( {{Sub}\text{-}{Function}\mspace{11mu} 3.6} )\end{matrix}$from sub-function 3.6 Calculate Total Other Cost/Incentive

-   -   Summed energy

$\begin{matrix}{\sum\limits_{a = 1}^{A}\;{{{\hat{P}}_{G,a,n} \cdot \Delta}\; t_{n}}} & ( {{Function}\mspace{11mu} 10} )\end{matrix}$that is predicted to be imported and/or generated at this transactivenode as has been calculated in function 10. Sum Total PredictedResource.

Outputs:

-   -   One current output TIS time series for this transactive node

Function/Process:

This sub-function simply adds the individual cost summations fromsub-functions 3.2, 3.3, 3.4, 3.5, and 3.6 and divides that sum by thetotal energy that is imported into or generated within the boundaries ofthis transactive node as was summed by sub-function 3.7:

$\begin{matrix}{{\frac{\begin{matrix}{{\sum\limits_{a = 1}^{A}\;{{C_{E,a,n} \cdot {\hat{P}}_{G,a,n} \cdot \Delta}\; t_{n}}} +} \\{{\sum\limits_{b = 1}^{B}\;{C_{C,b,n} \cdot {\hat{P}}_{C,b,n}}} + {\sum\limits_{c = 1}^{C}\;{{C_{I,c,n} \cdot \Delta}\; t_{n}}} + {\sum\limits_{d = 1}^{D}\; C_{O,d,n}}}\end{matrix}}{\sum\limits_{a = 1}^{A}\;{{{\hat{P}}_{G,a,n} \cdot \Delta}\; t_{n}}},{or}}{{TIS} = \frac{\begin{matrix}{{{energy}\mspace{14mu}{cost}} + {{capacity}\mspace{14mu}{cost}} +} \\{{{infrastructure}\mspace{14mu}{cost}} + {{other}\mspace{14mu}{costs}}}\end{matrix}}{Energy}}} & ( {{Sub}\text{-}{Function}\mspace{11mu} 3.7} )\end{matrix}$

The function shown above for interval n should be performed for allintervals that are to be used by the Demonstration for its transactivesignals.

Dependencies:

-   -   Will use sub-function 3.10 Interpolate Intervals Service        Functions to convert intervals of inputs into those of the        updated IST time series that is to be used by the output TIS.    -   The output TIS produced by this sub-function is one of the two        transactive signals that function 7. Send Transactive Signals        will act upon and send.

Notes:

-   -   This function assumes that intervals have been aligned and        modified to be consistent with the new IST intervals that were        determined by process 2. Calculate New Transactive Signal        Intervals. If that is not the case, the sub-function 3.10        Interpolate Intervals Service Functions should be applied until        inputs to this sub-function have been stated in terms of the IST        intervals for which the output TIS will be produced.    -   If properly formulated, the units of TIS will be cost per        energy. Dimensional unit analysis is a candidate component for        conformance testing to be performed on any implementation that        follows this toolkit framework.

4. Formulate TFS

Purpose:

Formulate one current transactive feedback signal (TFS) for theelectrical interface between this transactive node and each of itstransactive neighbors.

Applicability:

This process should be completed at the update frequency by transactivenodes.

Sub-Functions and Sub-Processes:

4.1 Interpolate Intervals Service Functions—function, or set offunctions, by which the inputs to this process may be restated using thecurrent interval start time (IST) series. If input time series are foundto use dated time intervals or any other representation of futureintervals other than the current IST series, this function should becalled until the dissimilarities are resolved. This function should alsobe called early during an update interval iteration to create updated,default versions of a recent prior transactive feedback signals (TFS)that may be used if, for any reason, this transactive node fails toformulate a TFS by the time it is used.

4.2 Predict Net Resource Surplus or Shortage—take the difference betweentotal resource from A resources and total load supplied by thistransactive node to determine the net surplus or shortage for eachfuture interval n. The net surplus or shortage is the average power overan interval that should be sent to or received from transactiveneighbors during that interval—an imbalance anticipated to occur at thistransactive node. Therefore, the net surplus or shortage should equalthe sum of all changes to the TFS for each interval at this transactivenode.

$\begin{matrix}{{\sum\;{TFS}_{n}} = {{\sum\limits_{a = 1}^{A}\;{\hat{P}}_{G,a,n}} - {\sum\;{\hat{L}}_{n}}}} & ( {{Sub}\text{-}{Function}\mspace{11mu} 4.2} )\end{matrix}$

Total average load at each interval Σ{circumflex over (L)}_(n) is acalculated input that should be retrievable from the Predicted Inelasticand Elastic Load Buffer. The total resource

$\sum\limits_{a = 1}^{A}\;{\hat{P}}_{G,a,n}$is a calculation available from the Total Predicted Resource Buffer, aproduct of 10. Sum Total Predicted Resource. (Desirably, there is aconnection between this calculated imbalance and resource planning.)

4.3 Disaggregate Net Resource Surplus or Shortage—allocate the netresource surplus or shortage among this transactive node's transactiveneighbors by formulating or modifying the TFS for each such interface.The newly formatted TFS are then stored into the Output TFS Buffer.

Today, this prediction would rely on centralized power-flow solvers. Ina fully distributed system, however, new prediction tools can be used.

This transactive node object should supply to this sub-function thecurrent list of transactive neighbors for which TFS should becalculated. It may also provide simple ratios or detailed topologicalinformation that can be used eventually to predict load flow betweenthis transactive node and its transactive neighbors, e.g., TFS series.Current information about the transactive node object is assumed to beavailable from a Node State and Status Buffer.

4.4 Refresh Default Output TFS—early during each IST update interval,this process should refresh the last calculated versions of TFS found inthe Output TFS Buffer and restate them using the current IST series.Thereafter, the restated, refreshed TFS may be returned to the bufferand used as default values if, for any reason, this transactive nodeshould fail to formulate the current TFS by the time they are used.

Inputs:

-   -   Predicted total load supplied Σ{circumflex over (L)}_(n) at each        future interval n of the current IST series from the Predicted        Inelastic and Elastic Load Buffer    -   Predicted total resource

$\sum\limits_{a = 1}^{A}\;{\hat{P}}_{G,a,n}$at each future interval n of the current IST series. (This is nowcalculated by a sub-function of this process, but it can be madeavailable from a common buffer of the toolkit framework.) This inputshould be available from the Total Predicted Resource Buffer.

-   -   Information from this transactive node object concerning its        transactive neighbors that should expect to receive a TFS from        this transactive node, available from the Node State and Status        Buffer.    -   Information from this transactive node's object that will be        used to allocate, or disaggregate, the net surplus or shortage        among the TFS that are to be stated form each transactive        neighbor, available from the Node State and Status Buffer.    -   The current IST series available from the Current IST Series        Buffer.

Outputs:

-   -   One output TFS for each transactive neighbor stored into and        available from the Output TFS Buffer.

Function/Process:

Refer to the descriptions of the sub-functions above as thesub-functions were being introduced.

Dependencies:

-   -   This process formulates one of two transactive signal types that        should be available from the Output TFS Buffer to be conveyed by        this transactive node to its transactive neighbors at the update        frequency by 7. Send Transactive Signals.    -   This process expects that the current IST series will have been        created by 2. Calculate New Transactive Signal Intervals and        available from the Current IST Series Buffer.    -   This process expects that the current sum total load will have        been calculated by function 5. Sum Total Predicted Load and        available from the Predicted Inelastic and Elastic Load Buffer.    -   This process expects that the total predicted resource will have        been calculated by function 10. Sum total Predicted Resource.

Notes:

-   -   The TFS is indeed a feedback signal, but the transactive control        and coordination system is not a closed-loop feedback control        system in the classical sense. First, the magnitude of resource        from responsive asset systems is too small for us to expect        closed-loop control. Second, the TIS is decidedly grounded as a        meaningful delivered cost of energy, not free to represent large        incentive swings as could a local marginal price. There is weak        or no integral control in the system.    -   The transactive feedback signal (TFS) may not be as dynamic and        useful as the transactive incentive signal (TIS) will be. The        TFS will be affected by a relatively small fraction of        responsive asset systems at places throughout the transactive        control and coordination system. Transmission and generation        entities are unengaged by the project's scale and are therefore        unresponsive to changes that will be observed in the TFS.

FIG. 39 is a flowchart 3900 of an exemplary formulate TFS process

5. Sum Total Predicted Load

Purpose:

Process to add the total inelastic (non-transactive) and elastic(transactive) electrical load components being supplied within theboundaries of this transactive node. (In the illustrated embodiment,electrical energy that is to be exported outside the boundaries of atransactive node is not part of this sum.)

Applicability:

This function applies to transactive nodes and should be updated at theupdate frequency; however, this process becomes trivial for transactivenodes that supply no elastic electric load, no inelastic electric load,or neither elastic nor inelastic electric load within the boundaries ofthe transactive node.

Sub-Functions and Sub-Processes:

5.1 Interpolate Intervals Service Functions—suite of functions that maybe called upon should any inputs to this function note yet exist usingthe current set of interval start times that should be available fromthe Current IST Series Buffer.

5.2 Sum Inelastic Load—sums the entries in the Inelastic Load PredictionBuffer that are relevant to the current update interval iteration.

The Inelastic Load Prediction Buffer may (or may not) have amultiplicity of relevant entries that should be summed. For example thebuffer might possess a bulk load prediction that is simply based onhistorical trends over the past week, the inelastic prediction for alarge water heater responsive asset system, and the inelastic predictionfor a voltage-response asset. (In certain embodiments, care should betaken not to double count any of the load as this sum is taken.) Foreach of this component addends k, the buffer should possess a relativelycurrent entry L_(inelastic,k). Each entry should state average load(unit: average power) to be consumed (or generated) by it during each ofa series of intervals.

If an entry from the buffer is found to have intervals other than thosein the current IST series, function 5.1 Interpolate Interval ServiceFunctions should be called upon to resolve the discrepancy and restatethe entry contents using the current IST interval set.

Ideally, all current, relevant contents of the buffer will be evidentfrom the entries' interval start time IST₀ time. Preferably, the buffercontents that are to found and summed by this sub-function for eachiteration should be attributes of this transactive node, knowable fromthe contents of the Node State and Status Buffer.

The output product of this sub-function is a single time seriesΣL_(inelastic,n) that has summed components k.

5.3 Sum Change in Elastic Load—sums the entries in the Toolkit ResponseFunction Output Buffer that are relevant to the current update intervaliteration. If toolkit functions have been employed for responsive assetsystems at this transactive node, one or more entries will be found inthe buffer to be summed in this sub-function. Note that only the changein elastic load is to be found in the buffer and summed for eachinterval start time interval by this sub-function. For each of thiscomponent addends j, the buffer should possess a relatively currententry ΔL_(elastic,j). Each entry should state the change in average load(unit: average power) it predicted to be consumed (or generated) by itduring each of a series of intervals.

If an entry from the buffer is found to have intervals other than thosein the current IST series, function 5.1 Interpolate Interval ServiceFunctions should be called upon to resolve the discrepancy and restatethe entry contents using the current IST interval set.

As was the case for sub-function 5.3 above, the contents of the bufferthat are to found and summed by this sub-function for each iterationshould be an attribute of this transactive node, knowable from thecontents of the Node State and Status Buffer.

The output product from this sub-function is a single time seriesΣΔL_(elestic,n) that has summed components j.

5.4 Sum Total Inelastic and Change in Elastic Load—function by whichtotal inelastic load predictions and predicted changes in elastic loadare finally summed to calculate a total to be placed into the PredictedTotal Inelastic and Elastic Load Buffer. This function completes thesimple arithmetic sumΣL _(total,n) =ΣL _(inelastic,n) +ΣΔL _(elestic,n),  (Function 5.)where ΣL_(total,n) is the sum of total inelastic load ΣL_(inelastic,n)and total change in elastic load ΣΔL_(elastic,n) for IST interval n atthis transactive node.

5.5 Refresh Predicted Total Inelastic and Elastic Load—succeedingcalculations will expect that the predicted total inelastic and elasticload will be available according to current IST intervals. Therefore,early in each update interval interation, the most currentrepresentation of that sum should be located within the Predicted TotalInelastic and Elastic Load Buffer and subjected to function 5.1Interpolate Intervals Service Functions to recast the buffer contentsinto a default buffer entry that uses the current set of interval starttimes (IST). If for any reason this transactive node fails to laterupdate its prediction of the sum into the buffer, the default value maybe used instead.

Inputs:

-   -   Set of predicted inelastic load {L_(inelastic,1),        L_(inealstic,2), . . . , L_(inelastic,k), . . . ,        L_(inelastic,K)} for each of the K components of total inelastic        load, each of which predicts average load (units: average power)        for interval start time interval n. This set of entries should        be found from within the Inelastic Load Prediction Buffer.    -   Set of predicted changes to elastic load {ΔL_(elastic,1),        ΔL_(ealstic,2), . . . , ΔL_(elastic,j), . . . , ΔL_(elastic,J)}        for each of the J components of total change in elastic load,        each of which predicts change in average load (units: average        power) for interval start time interval n. This set of entries        should be found from within the Toolkit Response Function Output        Buffer.    -   Current interval start time (IST) series from the Current IST        Series Buffer    -   List of those members of the Inelastic Load Prediction Buffer,        if any, which are expected to be found and used by this process,        which list should be obtained from attributes of this        transactive node found in the Node State and Status Buffer.    -   List of those members of the Toolkit Response Function Output        Buffer, if any, which are expected to be found and used by this        process, which list should be obtained from attributes of this        transactive node found in the Node State and Status Buffer.

Outputs:

-   -   Total predicted load L_(total,n) for each of the current IST        intervals to be stored into the Predicted Inelastic and Elastic        Load Buffer.

Function/Process:

The steps of this process were stated above with the introductions ofsub-functions. Overall, the process completes the simple arithmetic sumΣL _(total,n) =ΣL _(inelastic,n) +ΣΔL _(elestic,n),  (Function 5)where ΣL_(total,n) is the sum of total inelastic load ΣL_(inelastic,n)and total change in elastic load ΣΔL_(elastic,n) for IST interval n atthis transactive node.

Dependencies:

-   -   Should call upon current inelastic load predictions from the        Inelastic Load Prediction Buffer having been updated frequently        by process 6. Predict Applicable Inelastic Load using        Trends/Models.    -   For those transactive nodes that have responsive asset systems        and therefore employ toolkit functions, this function expects        that current predictions of changes in elastic load are        available from the Toolkit Response Function Output Parameter        Buffer having been updated frequently by process Calculate        Applicable Toolkit Response Function(s).    -   The output from this function is an input to process 4.        Formulate TFS.

Notes:

-   -   If the prediction of current total elastic and inelastic load        components cannot be calculated promptly by the time they are        used by the transactive node, prior calculations from the        Predicted Inelastic and Elastic Load Buffer should be used by        process 4. Formulation TFS.    -   It would be ideal if inputs into and outputs from this function        were properly formatted using the current interval start time        series (IST) that should exist in the Current IST Series Buffer.        Keeping the current outputs of functions and processes aligned        with the current IST series will greatly simplify later        successive calculations. If that cannot be accomplished,        interpolation service functions should be called upon.    -   Implementers might choose to have this process additionally        interact with the system management layer. If, for example, this        transactive node fails to update its load predictions and        therefore uses default, buffered estimates, such events might be        counted and/or flagged to initiate notifications or alerts. Such        a capability would be nice to have, but it is probably not an        essential part of the toolkit framework. System management for        this process would serve business entities that are relevant to        the “generic” system implementation.

FIG. 40 is a flowchart 4000 of an exemplary sum total predicted loadprocess.

6. Calculate Applicable Toolkit Load Functions

Purpose:

This process block represents from zero to many specific toolkit libraryfunctions that may be incorporated into the toolkit framework here. Thetoolkit functions that become instantiated at this location shouldrepresent and predict elastic and inelastic loads and should result in areasonably complete and accurate prediction of the entire load that issupplied within the boundaries of this transactive node during each ISTinterval.

Most generally, these toolkit functions may be characterized by theirinputs and outputs and by their generalized functional responsibilitieswithin the toolkit framework. A template is developed for thespecification of toolkit functions (see SubAppendix B). Owners oftransactive nodes, who represent the unique perspective under which thistransactive node should be managed, should select and/or help createspecific toolkit function(s) that model the responsive asset systems andinelastic loads that they have or plan to implement. See Table 25 for anexample list of toolkit load functions.

Modular toolkit functions may be implemented and shared via combinationsof their functional descriptions, pseudo code implementations, andreference code, all of which are recommended components of therecommended toolkit function template.

The location of this block within the toolkit framework is intended fortoolkit functions that predict the behaviors of two different types ofloads:

-   -   responsive asset system—an elastic load m for which its toolkit        function predicts both its inelastic load component L_(m) and a        change in elastic load ΔL_(m) using the current output TIS and        often other local conditions as inputs.    -   inelastic load—other inelastic load component for which its        toolkit function predicts only its inelastic load component        L_(m).

Of interest are those responsive asset systems that can be applied tothe transactive control and coordination system. (In certainembodiments, responsive asset systems have been defined to be appliedwithin reliability or conservation and efficiency test cases as well.Not all responsive asset systems are being used in the transactivecontrol and coordination system test cases.) A toolkit function shouldbe defined for each unique implementation of each major type ofresponsive asset system. Each toolkit function should first calculatethe inelastic load L_(m), which predicts when and how much energy theresponsive asset system would consume if it were not influenced by theoutput TIS. The prediction of inelastic load component is placed intothe Inelastic Load Prediction Buffer. The toolkit function should thenpredict the change in elastic load ΔL_(m) that is caused by thecondition of the output TIS. The prediction of elastic load component isplaced into the Elastic Load Prediction Buffer. It is acceptable thatthe elastic load components may be zero during intervals when theresponsive asset system is not predicted to be engaged by the outputTIS.

Another output from a toolkit function should be a representation of theplanned control action by which the responsive asset system will beinduced to change its energy consumption in light of the state of theoutput TIS for each interval. For example, some responsive asset systemsmay be either active or curtailed (e.g., populations of water heaters),in which case a binary indicator might be used for each interval. Othersystems are able to enter any of multiple discrete levels of response(e.g., GE smart appliances), in which case one of several discretelevels should be specified for each interval. Still other systems mayprovide a continuum of possible responses and use a representation ofpercentage. (An interesting example of this continuum of responses willoccur where customers are provided a means to view the output TIS itselfon an in-home display and respond correspondingly with a continuum ofbehavioral responses.) Eventually, as time marches toward the intervalof interest and the interval becomes that of IST₀, the responsive assetsystem should be expected to take the predicted, prescribed action. Theimplementations of responsive asset systems will be diverse, but it isin the representation of these predicted, planned control actions wherestandardization may be particularly useful.

An example would probably be useful concerning the portion of predictedload that should be included in this process from elastic loads,including responsive asset systems. Electrical consumption by a set ofelectric water heaters may be predicted quite well from measured trendsand models of the water heaters and their owners' behaviors. The inputinformation or parameters that influence such trends and models mightinclude time of day, day of week, occupancy, outdoor temperature, andaverage outdoor temperature, for examples. In the toolkit framework,these pieces of information or parameters are referred to as other localconditions that should be available inputs if the transactive node is toaccurately predict the load consumed by the water heaters. Thesepredictions are to be completed within this process 6. PredictApplicable Toolkit Load Functions. The predicted load should be recordedfor each such system in the Inelastic Load Prediction Buffer. If uponreceipt of the current output TIS the water heaters would reduce theirload, the change (e.g., only the change) would be predicted in aparallel calculation path and would be stored into the Elastic LoadPrediction Buffer.

Toolkit functions can used to describe behaviors of individual devices.But the responsive asset systems of the Demonstration are primarily usedfor populations of devices. It is the statistical behavior of thepopulations, not individual devices that should be predicted.

Inelastic load components are similarly incorporated via their toolkitfunctions; however, no elastic load component should be created by thesefunctions. Candidate inelastic load predictions might include feeders ofresidential customers, where the load of the population could bepredicted from the time of day, average home square footage, averagehouse age, outdoor temperature, and perhaps still other localconditions.

Regardless of whether a given toolkit function describes an elastic oran inelastic load, a load should never appear on both the resource andload sides of the toolkit framework formulation for any single intervaln. Responsive asset systems may be either electrical loads or resources.Regardless, the toolkit functions whose influence is to be inserted atthis location will affect the formulation of the TFS but will notdirectly influence the formulation of the output TIS. Responsive assetsystems that should affect the delivered cost of energy (e.g., the TIS)at this transactive node should be inserted at location 8. CalculateApplicable Toolkit Resource Functions instead.

Using the above-stated criterion, the average power from a customer'srenewable generator should probably be treated as a “negative” load(e.g., its toolkit function should be incorporated here) if it willnever result in net metering. But if the utility at any time pays thecustomer net-metering payments for surplus energy that is produced bythe resource, the resource should be included instead among resources,not loads, so that the net-metering charges may influence theformulation of the TIS (e.g., a toolkit function should be included forthis system in the process 8. Calculate Applicable Toolkit ResourceFunctions).

Using the same reasoning, the present process should not predict bulkgeneration resources that are scheduled at this transactive node becausecosts should almost certainly be applied to the energy from such bulkresources.

The influences of elastic and inelastic load components should never bedouble counted. The influence of a load should appear only once if anaccurate prediction of total load is to be formulated by thistransactive node.

Toolkit functions may include learning algorithms and other means toimprove the accuracy of their load predictions over time, but suchcomplexities should be weighed against the Demonstration's desire tocreate and teach and implement these toolkit functions with itsparticipants and within a tight development schedule.

See Table 25 for a list of example toolkit load functions.

Applicability:

Any toolkit functions to be called upon in this process block should becalled at the update frequency. It is conceivable but unlikely that atransactive node may have neither inelastic nor elastic load componentsthat necessitate any toolkit functions be called within this processblock.

Sub-Functions and Sub-Processes:

6.1 Interpolate Intervals Service Functions—a suite of service functionsthat may be called upon as they are desired to restate dated time seriesin terms of the current IST intervals. (These functions might be definedand used throughout the entire toolkit framework instead of uniquelydefined for each process, as has been shown here.)

6.2m Toolkit Load Function—from zero to many individual toolkitfunctions from a toolkit function library that predict inelastic loadand change in elastic load for each interval of the current IST series.Enough such toolkit functions should be incorporated and called upon topredict the entire load at this transactive node. Individual toolkitfunctions may be created or selected from a toolkit function librarypredict the behaviors of a responsive asset system; the behaviors of agroup of inelastic loads; generation from small distributed generationresources that do not directly influence the formulation of the TIS; orlarge nebulous groups of ill-defined loads that can only becharacterized by their historical trends.

It should be assumed that the list of M relevant toolkit functions areidentified and known by this transactive node object and is availablefrom the Node State and Status Buffer. Furthermore, the buffer shouldidentify the sets of other local conditions inputs expected to beavailable to the M toolkit functions from the Toolkit Load FunctionInput Buffer.

A toolkit function should output its prediction of inelastic load intothe Inelastic Load Prediction Buffer for the load being described andfor a current IST interval. (The inputs expected by toolkit functionswill be varied and may be dynamic.) If the function models and helpscontrol responsive, elastic loads, the function should also create andoutput the planned control for the responsive load. A standardizedadvisory control signal to be sent to the responsive asset systems hasbeen formulated and is available in SubAppendix C.

6.3 Refresh Predicted Inelastic Elastic Loads—early each update intervaliteration, the most current contents of the Inelastic Load PredictionBuffer and Elastic Load Prediction Buffer should be retrieved by thissub-function and restated using 6.1 Interpolate Intervals ServiceFunctions in terms of the current IST interval set. These updated buffercontents are then available to be used by default should thistransactive node fail for any reason to calculate its load for thecurrent iteration.

Inputs:

-   -   current IST interval series that is available from the Current        IST Series Buffer    -   current output TIS (units of “value” attribute: cost per energy)        from the Output TIS Buffer    -   other local conditions (OLC) (units: various) as might be        prescribed by specific toolkit functions and available from the        Toolkit Load Function Input Buffer    -   list of M toolkit functions that should be called at this        transactive node and the list of other local conditions data        inputs that will be used by the toolkit functions as should be        known by this transactive node object and available from the        Node State and Status Buffer.

Outputs:

-   -   Inelastic load predictions L_(m) (units: average power) for each        IST interval stored into the Inelastic Load Prediction Buffer    -   Elastic load predictions ΔL_(m) (units: change in average power)        for each IST interval stored into the Elastic Load Prediction        Buffer    -   Predicted control actions for responsive asset systems for each        IST interval stored into the Elastic Load Prediction Buffer.        (recommendation for units: {allowed: “0”; curtailed: “−1”};        {generation level L: “L”; . . . , generation level 2: “2”;        generation level 1: “1”; off: “0”; load reduction level−1: “−1”;        load reduction level−2: “−2”; . . . }; {continuum from full        generation: “100”; off: “0”; full load reduction: “−100})

Function/Process:

Sub-functions 6.1 and 6.3 were described as they were being introducedin the text above. This document has stated functional responsibilitiesand an input/output model for the multiplicity of toolkit functions 6.2mToolkit Load Function that are to be called upon during this process.Each toolkit function should use the provided template and shoulddescribe for itself what it is meant to accomplish within the functionalresponsibilities, inputs, and outputs that have been generally describedhere.

Dependencies:

-   -   The current TIS should have been calculated by 3. Formulate TIS        and available from the Output TIS Buffer.    -   Various current other local conditions should be available from        the Toolkit Load Function Input Buffer. The list of relevant        other local conditions should be known to the transactive node        object and available from the Node State and Status Buffer. Note        that the other local conditions might themselves use management        of other data collection and maintenance systems and processes.    -   A list of functions 6.2m Toolkit Load Functions should be        unambiguously named and known to this transactive node object        available from the Node State and Status Buffer.    -   Process 2. Calculate New Transactive Signal Intervals should        have run recently to provide to this process current IST        intervals available from the Current IST Series Buffer.    -   This process inserts up to M entries into each the Inelastic        Load Prediction Buffer and Elastic Load Prediction Buffer, one        for each toolkit function that is called. The contents of these        buffers should be current and available to be summed by        process 5. Sum Total Predicted Load.

Notes:

-   -   No load or resource should appear on both the load and resource        sides of the toolkit formulation for any given IST interval.    -   The sum of the inelastic load stored into the Inelastic Load        Prediction Buffer and change in elastic load stored into the        Toolkit Response Function Output Buffer for a give toolkit        function should closely predict the actual load, providing the        TIS and other local condictions (OLC) remain about the same        until the corresponding IST_(n) interval becomes IST₀.    -   It is hoped but not required that model-based predictions of        both the inelastic-load and change in elastic-load components        may improve over time as more sophisticated toolkit functions        use historical feedback to improve their algorithms.    -   Implementers are encouraged to use this process and its toolkit        functions for model-based load predictions, regardless of        whether they describe elastic load.

TABLE 25 Example Resource, Incentive and Load Toolkit Functions Resourceor Incentive Load 1.0 Imported Electrical Energy 1.0 Bulk Inelastic Load1.1 Non-Transactive Imported 1.1 Bulk Commercial Load Energy 1.2 BulkIndustrial Load 1.2 Transactive Imported 1.3 Bulk Residential LoadEnergy 1.4 Small Wind Generator Negative Load 2.0 Renewable Energy 1.5Small-Scale Distributed Generator Negative Load Resource 1.6 Small-ScaleSolar Generator Negative Load 2.1 Wind Energy 2.0 General Event-DrivenDemand Response 2.2 Solar Energy 2.1 Commercial Event-Driven DemandResponse 2.3 Hydropower 2.2 Event Driven Distribution System VoltageControl 3.0 Fossil Generation 2.4 Residential Event-Driven DemandResponse 4.0 General Infrastructure 2.5 Non-Renewable DistributedGeneration Event-Driven Cost Demand Response 5.0 System Constraints 3.0General Time-of-Use Demand Response 5.1 Transmission Flowgate 3.1Battery Storage--Time-of-Use 5.2 Equipment and Line 3.2 CommercialTime-of-Use Demand Response Constraints 3.4 Residential Time-of-UseDemand Response 6.0 System Energy Losses 3.5 Time-of-Use DistributionSystem Voltage Control 6.1 Transmission Losses 3.6 Time-of-Use ElectricVehicle Charging 6.2. Distribution Losses 4.0 General Real-TimeContinuum Demand Response 7.0 Demand Charges 4.1 BatteryStorage--Real-Time 7.1 BPA Demand Charges 4.2 Commercial Real-TimeDemand Response 8.0 Market Impacts 4.3 Real-Time Distribution SystemVoltage Control 8.1 Spot Market Impacts 4.5 Residential Real-Time DemandResponse 5.0 General Manual or Behavioral Demand Response 5.1Residential Behavioral Response to Portals or In-Home Displays 5.2Residential Behavioral Response--No Portals or In- Home Display 5.3Manual Commercial Demand Response 5.4 Manual Non-Renewable DistributedEnergy Resources Demand Response

FIG. 40 is a flowchart 4000 of an exemplary “calculate applicabletoolkit load functions” process.

7. Send Transactive Signals

Purpose: Method by which output transactive signals are conveyed fromthis transactive node to each one of its transactive neighbors. Mostgenerally, there will be no single approach to completing this processbecause transactive is tied to no single communication technology,medium, or protocol. Transactive neighbor pairs should negotiate andagree upon these details. On the other hand, the Demonstration haselected to convey transactive signals almost exclusively via secureInternet.

Applicability:

An process that should be completed at the update frequency by atransactive node.

Sub-Functions and Sub-Processes:

The following high-level responsibilities should be addressed,regardless of the platforms on which it is designed:

-   -   Format transactive signals according to published        recommendations, including published XML schema.    -   Coordinate timing with transactive node object states during        each update interval and iteration    -   Compare and coordinate Transactive neighbor list with        transactive node object state.

Inputs:

-   -   One output TIS series from process 3. Formulate TIS    -   One output TFS series for each transactive neighbor from        process 4. Formulate TFS

Outputs:

-   -   Paired couples of output TIS and output TFS sent to each        transactive neighbor.

Dependencies:

-   -   Receives current output TIS from Output TIS Buffer

Notes:

-   -   This process or function is trivial from a functional        perspective, but it is useful from a system interoperability        perspective. Transactive nodes that employ unlike software and        computational architectures should still be able to send and        receive these signals from their transactive neighbors.

This function or process is also useful from a cyber-securityperspective. Both the senders and recipients of transactive signalsshould be satisfied that their systems will remain safe from attack.

FIG. 43 is a flowchart 4300 of an exemplary “send transactive signals”process.

8. Calculate Applicable Toolkit Resource and Incentive Functions

Purpose:

A multiplicity of toolkit functions may be applied at this locationwithin the toolkit framework to address resources and incentives.Toolkit functions should be created or selected from a toolkit libraryto represent the energy resources and incentives that are be applied atthis transactive node during each IST interval. The costs that arecalculated by the toolkit functions in turn may incentivize ordisincentivize consumption and generation of electricity through theireffects on the transactive incentive signal.

See Table 25 for a list of example toolkit resource and incentivefunctions. Refer to SubAppendix B for a template that may be used tospecify additional toolkit resource and incentive functions as they aredeveloped.

Applicability:

A transactive node should calculate at least one toolkit function at theupdate frequency.

Sub-Functions and Sub-Processes:

8.1 Interpolate Intervals Service Functions—a suite of service functionsthat can accept stale, dated data and restate the data in terms of thecurrent IST interval series. (These functions might be defined and usedthroughout the entire toolkit framework instead of uniquely defined foreach process, as has been shown here.)

8.2 Refresh Predicted Resources and Incentives—Early during each updateinterval, this sub-function retrieves the most recent entries from theResource Schedules and Cost Buffer and restates the records in terms ofthe current IST series. If for any reason this transactive node fails tocomplete the present process by the time its outputs are used, therestated records may be used as default records.

8.3 Assign Energy Cost and Average Power—a sub-function of a toolkitresource and incentive function in which cost C_(E,a,n) (units: cost perenergy) is assigned to each component a of energy {circumflex over(P)}_(G,a,n) (units: average power) that is either imported into orgenerated within the boundaries of this transactive node. In particularembodiments, one responsibility of a toolkit resource and incentivefunction is to calculate and report one of each of these two quantitiesfor each current IST interval n. Either of the calculated quantities maybe zero. The calculated values will differ depending on selected toolkitfunction and the resource or effect that is being modeled by theselected toolkit function.

Example energy costs and energies that that should be captured usingthis sub-function include

-   -   The cost of energy from traditional bulk generation    -   The cost of energy from renewable energy resources like wind.        (Wind energy is desirably incentivized by applying its costs to        its infrastructure and not to the energy that is produced.        Thereby, it causes a downward influence on the delivered cost of        energy at the time and near where wind blows.)    -   For non-transactive neighbors, the cost of energy that applies        to any energy that is imported into the boundary of this        transactive node. (Note that if energy is exported rather than        imported during an IST interval n, it is not counted among        resources, so either or both the energy terms for this        sub-function should be set to zero.)    -   For transactive neighbors, the cost of delivered energy (e.g.,        the TIS) that applies to imported energy (e.g., the TFS). (This        is a special case where the input TIS and input TFS are read        from the Input Transactive Signal Buffer. A simple toolkit        function should be created to complete this task.)

The values C_(E,a,n) should be defensible representations of thedelivered costs of energy {circumflex over (P)}_(G,a,n).

The sum of {circumflex over (P)}_(G,a,n) should represent the energythat is generated within or imported into this transactive node duringIST interval n.

This sub-function may call upon various defined other local conditionsthat should be available as inputs from the Resource and incentive InputBuffer. The list of other local conditions that are expected by a givetoolkit function should be known by the transactive node object andavailable from the Node State and Status Buffer.

Refer to sub-function 3.7 Calculate Output TIS to fully understand howthe two outputs from the present sub-function will become incorporatedinto the formulation of TIS within the toolkit framework.

8.4 Assign Capacity Cost and Capacity—a sub-function of a toolkitresource and incentive function in which cost C_(C,b,n) (units: cost perpower) is assigned to capacity limitations and costs that are triggeredby capacities. The sub-function also captures the capacity {circumflexover (P)}_(C,b,n) (units: average power) to which the cost applies. Incertain embodiments, one responsibility of a toolkit resource andincentive function is to calculate one of each of these two quantitiesfor each current IST interval n. Either of the calculated quantities maybe zero. The calculated values will differ depending on selected toolkitfunction and the resource or effect that is being modeled by theselected toolkit function.

Example capacity costs that should be included through this sub-functioninclude

-   -   Costs that should be applied as equipment like power lines        become constrained    -   Imposed demand charges that become applied to the owners of this        transactive node.

Cost C_(C,b,n) should be defensible as cost that will be incurred upon acorresponding capacity {circumflex over (P)}_(C,b,n) that is predictedto occur during IST interval n.

This sub-function may call upon various defined other local conditionsthat should be available as inputs from the Resource and incentive InputBuffer. The list of other local conditions that are expected by a givetoolkit function should be known by the transactive node object andavailable from the Node State and Status Buffer.

Refer to sub-function 3.7 Calculate Output TIS to fully understand howthe two outputs from the present sub-function will become incorporatedinto the formulation of TIS within the toolkit framework.

8.5 Assign Infrastructure Cost—a sub-function of a toolkit resource andincentive function in which cost C_(I,c,n) (units: cost per time) isassigned to the provision of infrastructure at this transactive node,which costs are usually spread over quite long periods of time. Incertain embodiments, one responsibility of toolkit resource andincentive function is to calculate and report one infrastructure costoutput for each current IST interval n. Its value may be zero. Thecalculated value will differ depending on selected toolkit function andthe resource or effect that is being modeled by the selected toolkitfunction.

Example infrastructure costs that may be used through this sub-functioninclude

-   -   Initial purchase costs for equipment    -   Initial installation costs    -   Maintenance costs.

Refer to sub-function 3.7 Calculate Output TIS to fully understand howthe output from the present sub-function will become incorporated intothe formulation of TIS within the toolkit framework.

8.6 Assign Other Costs—a sub-function of a toolkit resource andincentive function in which other costs (units: cost) that cannot berepresented by the other sub-functions are applied at this transactivenode. In certain embodiments, one responsibility of a toolkit resourceand incentive function is to calculate and report one such other costoutput for each current IST interval n. Its value may be zero. Thecalculated value will differ depending on selected toolkit function andthe resource or effect that is being modeled by the selected toolkitfunction.

This sub-function should not be used to bypass the other threesub-functions 8.3, 8.4, and 8.5. The other cost that is assigned by thissub-function should be a defensible component of the delivered cost ofenergy (e.g., the TIS) that will be formulated by process 3. FormulateTIS.

Refer to sub-function 3.7 Calculate Output TIS to fully understand howthe output from the present sub-function will become incorporated intothe formulation of TIS within the toolkit framework.

Inputs:

-   -   Current Input TIS and TFS should have been received in        process 1. Receive Transactive Signals and should be available        from the Input Transactive Signal Buffer. These inputs will be        treated the same as other energy terms.    -   Current other local conditions data that has been specified for        by the set of toolkit functions that are being applied at this        transactive node.    -   The list of toolkit functions that are to be applied in this        process, which list should be known to this transactive node        object and available from the Node State and Status Buffer.    -   The list of other local conditions data records that are        expected by the set of toolkit functions that are employed in        this process block, which list should be known by this        transactive node object and available from the Node State and        Status Buffer.

Outputs:

-   -   One paired energy cost and energy (C_(E,a)·{circumflex over        (P)}_(G,a)) series record placed into and available from the        Resource Schedules and Cost Buffer for each of the toolkit        functions that is applied within this process. (There are A        non-zero of these records used to represent imported and        generated energy.)    -   One paired capacity cost and capacity (C_(c,b)·{circumflex over        (P)}_(C,b)) series record placed into and available from the        Resource Schedules and Cost Buffer for each of the toolkit        functions that is applied within this process. (There are B        non-zero of these records where capacity costs are relevant.)    -   One infrastructure cost C_(I,c) series record placed into and        available from the Resource Schedules and Cost Buffer for each        of the toolkit functions that is applied within this process.        (There are C non-zero of these records where infrastructure        costs are relevant.)    -   One other cost C_(O,d) series record placed into and available        from the Resource Schedules and Cost Buffer for each of the        toolkit functions that is applied within this process. (There        are D non-zero of these records where other costs are relevant.)

Function/Process:

The sub-functions were described above as they were being introduced.Sub-functions 8.3, 8.4, 8.5, and 8.6 are components of toolkit functionsand may not be generically defined except through the characterizationof their inputs and outputs.

Dependencies:

-   -   This process should find current input transactive signals from        process 1. Receive Transactive Signals from within the Input        Transactive Signal Buffer.    -   This process expects current and relevant other local conditions        are available from the Resource and Incentive Input Buffer. The        list of example other local conditions records is known to this        transactive node object and available from the Node State and        Status Buffer.    -   This process expects that the relevant list of toolkit functions        will be known to the transactive node object and available from        the Node State and Status Buffer. The modular toolkit functions        themselves should be available at the transactive node.    -   This process expects that the current IST series will have been        calculated by process 2. Calculate New Transactive Signal        Intervals and will be available from the Current IST Series        Buffer.    -   This process outputs to the Resource Schedules and Cost Buffer        that are used for processes 10. Sum Total Predicted Resource and        by 3. Formulate TIS.

Notes:

-   -   A transactive node should instantiate at least one toolkit        function that redefines current transactive signals as energy        terms and places them into the Resource Schedules and Cost        Buffer.    -   General guidance should be that a transactive control and        coordination system can address economic decisions that interact        with the system somewhat slower than the update frequency. There        will occur an interim period where the Demonstration's system        will accept but not influence resource decisions that presently        involve markets and ancillary services that are not initially        tied into the transactive control and coordination system.        However, many such economic decisions may be addressed and        perhaps optimized by a transactive control and coordination        system as theories are developed to support doing so.    -   An alternative pathway has been provided for “Scheduled        Resources” to become entered into the Resource Schedules and        Cost Buffer. It is preferred, however, that even non-transactive        resources enter into the toolkit framework via a toolkit        function and this process 8. Calculate Applicable Toolkit        Resource and Incentive Functions. One of our most basis toolkit        functions should be one that represents traditional, bulk        generation.

FIG. 43 is a flowchart 5300 of an exemplary “calculate applicabletoolkit resource and incentive functions” process.

9. Control Responsive Asset Systems

Purpose:

Advise responsive asset systems of the actions that they should takeduring the present update interval in accordance with their plannedresponses for the current interval start time IST₀.

Applicability:

This process should be completed at the update frequency by atransactive node that has at least one responsive asset system installedand responsive to the transactive control and coordination system.

Some transactive node owners will impose constraints on the dynamicswith which their responsive asset systems may act, in which case thisprocess may be completed less frequently than the update frequency. Forexample, certain responsive asset systems may be engaged only at the topof an hour and may remain engaged for minimum durations after that.Still others should be scheduled some time prior and are therefore notresponsive to the update frequency. (The capabilities of variousresponsive asset systems are desirably addressed in the selected toolkitlibrary functions 6.2m Toolkit Load Function.)

Sub-Functions and Sub-Processes:

None. This process may be only described at a functional level due tothe diversity of the responsive asset system that is to be controlled.Most of the actual control activities take place within the responsiveasset systems themselves and according to the preferred practices ofthis transactive node's owner.

Inputs:

-   -   Advisory signal for current interval start time IST₀ that is        available from the Elastic Load Prediction Buffer. Each of these        inputs is expected to have one of three meanings depending upon        the capabilities of the targeted responsive asset        system—discrete binary, discrete multilevel, or continuous.

Outputs:

-   -   The principal output actually occurs outside the transactive        control and coordination system and outside this process but in        the final control of the assets within the target responsive        asset system.    -   The state or status of the responsive asset system may be        updated to the Node State and Status Buffer. For example, this        buffer may hold information about the availability of the system        or the amount of load that is presently available to be        controlled.

Function/Process:

The process by which the advisory output found within the Elastic LoadPrediction Buffer is to be converted into control actions for thepresent update interval will be quite unique to the responsive assetsystem and will take place within the system according to practices ofthis transactive node's owner.

Dependencies:

If this transactive node possesses any responsive asset systems, then

-   -   This process expects to find a current advisory response for        each respective responsive asset system having been predicted        (planned) by its respective process 6. Calculate Applicable        Toolkit Load Functions and available in the Elastic Load        Prediction Buffer. Only the current interval start time IST₀ is        relevant to the actual, not the planned, control of a responsive        asset system.

Notes:

-   -   Note that the toolkit function that corresponds to a given        responsive asset system should state the information about the        system that should be maintained within the Node

State and Status Buffer.

-   -   Responsive asset systems may be either energy loads or        resources.    -   The transactive control and coordination system advises a        responsive asset system via this process, but it never directly        controls any responsive asset system. A responsive asset system        is not part of the transactive control and coordination system.    -   Responsive asset systems are very diverse. Even similar asset        systems use different approaches, practices, protocols, and        standards. One might realize an opportunity for standardization        in the three types of signals that will be used to advise        control actions for responsive asset systems—discrete binary,        discrete multilevel, and continuous.    -   For the Demonstration, responsive asset systems almost        exclusively refer to populations of individual assets. The        Demonstration's transactive control and coordination system        therefore will provide an advisory “control” signal to the        system, not to its individual assets. If use of transactive        control and coordination systems continues, it is feasible that        they will be extended down to individual assets. In principle, a        transactive control and coordination system is very scalable.

FIG. 44 is a flowchart 5400 of an exemplary “control responsive assetsystems” process.

10. Sum Total Predicted Resources

Purpose:

Sum the total energy resources entering the boundaries of thistransactive node. The transactive node that has A resources

The sum produced by this process is used for two purposes in the toolkitframework: First, it is the divisor in process 3. Formulate TIS. Second,during process 4. Formulate TFS it is compared against the total loadthat is calculated by process 5. Sum Total Predicted Load, resulting inthe net surplus or shortage of energy that should be allocated among theTFS of of transactive neighbors.

Applicability:

This process should be completed at the update frequency by atransactive node.

Sub-Functions and Sub-Processes:

10.1 Interpolate Intervals Service Functions—a suite of servicefunctions that may be called upon as they are desired to restate datedtime series in terms of the current IST intervals. (These functionsmight be defined and used throughout the entire toolkit frameworkinstead of uniquely defined for each process, as has been shown here.)

10.2 Sum Total Predicted Resource—sum of the A resources {circumflexover (P)}_(G,a,n) (units: average power) for each IST interval n. Thissub-function should find a current representation of each summand fromwithin the Resource Schedules and Cost Buffer. The expected set ofsummands should be known to this transactive node object and availablefrom the Node State and Status Buffer. The sum should include electricalenergy that is either generated within or imported into the boundariesof this transactive node during each IST interval n. Each of thesummands should be found paired with an energy cost parameter C_(E) inthe Resource Schedules and Cost Buffer.

Summands {circumflex over (P)}_(G,a,n) should include and represent

-   -   The TFS (units: average power) of each transactive neighbor from        which this transactive node will import energy during interval        n.    -   The average energy generated during IST intervals n from any        generator within the boundaries of this transactive node which        may be expected to influence the formulation of the TIS. That        is, its generated energy should be paid for and represented in        the transactive control and coordination system. (This will        include almost all generation resources. An exception will be        generation by end-use customers that displaces their load but        never should affect the cost energy in a way that would be        evident outside the customer premises.)    -   Energy imported during IST intervals n from electrically        connected neighbors who are not transactive neighbors.

$\begin{matrix}{{{Total}\mspace{14mu}{Predicted}\mspace{14mu}{Resource}} = {\sum\limits_{a = 1}^{A}\;{\hat{P}}_{G,a,n}}} & {{Process}\mspace{11mu} 10}\end{matrix}$

The output product from this sub-function is a single time series(units: average power) placed into the Total Predicted Resource Buffereach update interval.

10.3 Refresh Predicted Total Resource—early each update intervaliteration, the most current contents of the Total Predicted ResourceBuffer should be retrieved by this sub-function and restated using 10.1Interpolate Intervals Service Functions in terms of the current ISTinterval set. These updated buffer contents are then available to beused by default should this transactive node fail for any reason tocalculate total resource for the current iteration.

Inputs:

-   -   A multiplicity of resource components {circumflex over        (P)}_(G,a,n) (units: average energy) to be retrieved from the        Resource Schedules and Cost Buffer.    -   The identifiers of A resource components known by this        transactive node object and available from the Node State and        Status Buffer.    -   Current interval start time (IST) series available from the        Current IST Series Buffer.

Outputs:

-   -   Sum of resources

$\sum\limits_{a = 1}^{A}\;{\hat{P}}_{G,a,n}$(units: average power) stored into the Total Predicted Resource Buffer.This output is a series of values, one for each IST interval.

Function/Process:

The purpose of this process is to perform a mathematical sum, which hasbeen described above as the sub-functions were being introduced.

Dependencies:

-   -   This process uses a current IST series to have been calculated        by process 2. Calculate New Transactive Signal Intervals and        available from the Current IST Series Buffer.    -   This process expects that current resource components        {circumflex over (P)}_(G,a,n) will have been placed into the        Resource Schedules and Cost Buffer by process 8. Calculate        Applicable Toolkit Resource and Incentive Functions. However,        the sub-function 8.3 Refresh Predicted Resources and Incentives        will have created a default set of inputs that may be used here        if current inputs cannot be calculated.    -   The current output of this process is used by process 3.        Formulate TIS and 4. Formulate TFS and is expected to be        available from the Total Predicted Resource Buffer. However,        some resiliency is provided by sub-function 10.3 Refresh        Predicted Total Resource, which calculates a default current        process output to be available from the Total Predicted Resource        Buffer should this process fail to create a current output by        the time it is used.

Notes:

-   -   Refer to processes 3. Formulate TIS and 4. Formulate TFS that        will give one a better sense of how the output of this process        is to be used.    -   The general term {circumflex over (P)}_(G,a,n) has been        introduced, in part, to deemphasize that there are multiple        types of such terms, including even the TFS at time it describes        imported energy. Altogether, these terms should include the        energy that is generated or imported within this transactive        node's boundary.

This process was originally considered as a sub-function within bothprocesses 3 and 4. Because both processes performed the identicalfunction, the function was elevated to a process at thetoolkit-framework level so that the same sum may be used by bothprocesses 3 and 4.

FIG. 45 is a flowchart 4500 of an exemplary “sum total predictedresources” process.

11. Control Responsive Resource

Purpose:

Advise responsive resources of the actions that they should take duringthe present update interval in accordance with their planned responsesfor the current interval start time IST₀.

Applicability:

This process should be completed at the update frequency by atransactive node that has at least one responsive resource. This processwill be used infrequently until resources like bulk generators becomeresponsive to a dynamic transactive control and coordination system.

Some resource owners will impose constraints on the dynamics with whichtheir resources may act, in which case this process may be completedless frequently than the update frequency.

Sub-Functions and Sub-Processes:

None. This process may be only described at a functional level due tothe diversity of the resources that are to be controlled. Most of theresponsibilities to engage resources lie with the resource systemsthemselves and not with processes of the toolkit framework.

Inputs:

-   -   Resource plans as formulated by certain toolkit functions within        the process 8. Calculate Applicable Toolkit Resource and        Incentive Functions.

Outputs:

-   -   The principal output actually occurs outside the resource system        and outside this process but in the final control of the        resource within the target resource system.    -   The state or status of the resource may be updated to the Node        State and Status Buffer. For example, this buffer may hold        information about the availability of the system or the amount        of resource that is presently available to be controlled.

Function/Process:

The process by which the advisory output found within the ResourceSchedules and Cost Buffer is to be converted into control actions forthe present update interval will be quite unique to the responsiveresource system and will take place within the system according topractices of the resource and transactive node owners.

Dependencies:

If this transactive node possesses any responsive resource systems, then

-   -   This process expects to find a current advisory response for        each respective responsive resource system having been predicted        (planned) by its respective process 8. Calculate Applicable        Toolkit Resource and Incentive Functions and available in the        Resource Schedules and Cost Buffer. Only the current interval        start time IST₀ is relevant to the actual, not the planned,        control of a responsive resource system.

Notes:

-   -   Note that the toolkit function that corresponds to a given        responsive resource system should state the information about        the system that should be maintained within the Node State and        Status Buffer.    -   The transactive control and coordination system advises a        responsive resource system via this process, but it never        directly controls it. A responsive resource system is not part        of the transactive control and coordination system.    -   Responsive resource systems are very diverse. Even similar        systems use different approaches, practices, protocols, and        standards. One might realize an opportunity for standardization        in the three types of signals that will be used to advise        control actions for responsive resource systems—discrete binary,        discrete multilevel, and continuous.

FIG. 46 is a flowchart 4600 for an exemplary “control responsiveresource” process.

6.2.4 SubAppendix A: Interval Start Time Series Definition 6.2.4.1Purpose

This section recommends a specific set of 57 Interval Start Times (IST)for use in example embodiments of the disclosed technology, includingthe Demonstration. The intervals range in duration from 5 minutes to 1day. In this embodiment, the 57 ISTs define 56 intervals of varyingduration, though other numbers of IST and different durations can beused.

6.2.4.2 Series of 57 Interval Start Times Defined

The first interval in a set of Interval Start Times is IST₀. While atransactive signal is being formulated, IST₀ is the next future time atwhich the minute hand of a clock will be at one of the 12 majordivisions of an hour (e.g., on the hour, 5 minutes after the hour, 10minutes after the hour, etc.).

The series of time intervals to be used by transactive signals duringthe Demonstration are as defined in Table 26. This set of 56 intervalsis easily specified, creates the same numbers of intervals, exhibitsincreasing coarseness into the future, and will align well with dynamicmarket signals that are up to 1 hour in duration. Note that a 57^(th)IST (e.g., IST₅₆) has been added to unambiguously define the duration ofthe final, 56^(th) interval.

One variable-length interval resides at the boundary between sets ofintervals having different durations. That is, there is avariable-length interval between 5- and 15-minute intervals, between15-minute and 1-hour intervals, between 1- and 6-hour intervals, andbetween 6-hour and 1-day intervals. The duration of each variable-lengthinterval varies between the durations of the two bounding intervals,inclusive. No intervals overlap in the resulting representation of thefuture.

Five-minute intervals are to be used 1 hour into the future; 15-minuteintervals, 6 hours into the future; 1-hour intervals, 1 day into thefuture; 6-hour time intervals, 2 days into the future, and 1-dayintervals, 3 to 4 days into the future.

TABLE 26 Example Interval Time Series for use with TIS and TFS DurationNo. Intervals Interval Start Times 5 minutes 12 IST₀, IST₀ + 0:05, . . ., IST₁₀ + 0:05 15 minutes 20 Round(IST₁₁ + 0:15)*, IST₁₂ + 0:15, . . . ,IST₃₀ + 0:15 1 hour 18 Round(IST₃₁ + 1:00)*, IST₃₂ + 1:00, . . . ,IST₄₈ + 1:00 6 hours  4 Round(IST₄₉ + 6:00)*, IST₅₀ + 6:00, . . . ,IST₅₂ + 6:00 1 day  2 Round(IST₅₃ + 1:00:00)*, IST₅₄ + 1:00:00, IST₅₅ +1:00:00 >3 days 56 intervals 57 interval start times (IST) *Thisfunction “Round” indicates rounding down to the next 15-minute, 1-hour,6-hour, or 1-day interval start time. Times are indicated as dd:hh:mm,e.g., days, hours, and minutes.

The intervals of several time series that adhere to this recommendationare shown in Table 27 for several example values of IST₀.

6.2.4.3 Pseudo Code for Example IST Series

The following formula guides the calculation of the IST series accordingto the specification in Table 26. The interval start times use thenotationIST_(n)[dd _(n) ,hh _(n) ,mm _(n)],  (A1)where “dd” is days, “hh” is hours, and “mm” is minutes. The value nrefers to the sequential, ordered number of the IST in its series. Thetotal number of intervals in the series is N=56, where N is the last n.IST≐{IST₀,IST₁,IST₂, . . . ,IST_(n), . . . ,IST_(N)}  (A2)

The following steps and pseudo code should help standardize calculationof the members of an IST time series. The function “truncate( )”indicates that the decimal parts of the result in the parentheses shouldbe discarded.

(1) Calculate first element IST₀:

Read present time t

Set IST₀=t+0:05

Set mm₀=5*truncate (mm₀/5)

(2) Calculate the IST series for remaining 5-minute intervals:

For n=1 to 11

-   -   Set IST_(n)=IST_(n−1)+0:05    -   Next n

(3) Calculate the IST series for 15-minute intervals:

Set IST₁₂=IST₁₁+0:15

Set mm₁₂=15*truncate(mm₁₂/15)

For n=13 to 31

-   -   Set IST_(n)=IST_(n−1)+0:15    -   Next n

(4) Calculate the IST series for 1-hour intervals:

Set IST₃₂=IST₃₁+1:00

Set mm₃2=0

For n=33 to 49

-   -   IST_(n)=IST_(n−1)+1:00    -   Next n

(5) Calculate the IST series for 6-hour intervals:

Set IST₅₀=IST₄₅+6:00

Set hh₅₀=6*truncate(hh₅₀/6)

For n=51 to 53

-   -   IST_(n)=IST_(n−1)+6:00    -   Next n

(6) Calculate the IST series for 1-day intervals:

Set IST₅₄=IST₅₃+1:00:00

Set hh₅₄=0

Set IST₅₅=IST₅₄+1:00:00

(7) Append the final IST that indicates the end of the last 1-dayinterval:

Set IST₅₆=IST₅₅+1:00:00

6.2.4.4 Example IST Series

Table 27 lists the 57 IST time series elements for 13 example values ofIST₀. The number of intervals (56 for the Demonstration) and totaldescribed time duration, listed at the bottom of Table 27 for theseexamples, have been adopted as additional elements of the XML schemathat has been designed for the Demonstration's transactive signals.

TABLE 27 Interval Start Times at Example Next Interval Start TimesInterval # 0:00 0:05 0:10 0:15 0:30 0:45 1:00 3:00 5:00 6:00 12:00 18:001:00:00 5 min. 0 0:00 0:05 0:10 0:15 0:30 0:45 1:00 3:00 5:00 6:00 12:0018:00 1:00:00 1 0:05 0:10 0:15 0:20 0:35 0:50 1:05 3:05 5:05 6:05 12:0518:05 1:00:05 2 0:10 0:15 0:20 0:25 0:40 0:55 1:10 3:10 5:10 6:10 12:1018:10 1:00:10 3 0:15 0:20 0:25 0:30 0:45 1:00 1:15 3:15 5:15 6:15 12:1518:15 1:00:15 4 0:20 0:25 0:30 0:35 0:50 1:05 1:20 3:20 5:20 6:20 12:2018:20 1:00:20 5 0:25 0:30 0:35 0:40 0:55 1:10 1:25 3:25 5:25 6:25 12:2518:25 1:00:25 6 0:30 0:35 0:40 0:45 1:00 1:15 1:30 3:30 5:30 6:30 12:3018:30 1:00:30 7 0:35 0:40 0:45 0:50 1:05 1:20 1:35 3:35 5:35 6:35 12:3518:35 1:00:35 8 0:40 0:45 0:50 0:55 1:10 1:25 1:40 3:40 5:40 6:40 12:4018:40 1:00:40 9 0:45 0:50 0:55 1:00 1:15 1:30 1:45 3:45 5:45 6:45 12:4518:45 1:00:45 10 0:50 0:55 1:00 1:05 1:20 1:35 1:50 3:50 5:50 6:50 12:5018:50 1:00:50 11 0:55 1:00 1:05 1:10 1:25 1:40 1:55 3:55 5:55 6:55 12:5518:55 1:00:55 15-min. 12 1:00 1:15 1:15 1:15 1:30 1:45 2:00 4:00 6:007:00 13:00 19:00 1:01:00 13 1:15 1:30 1:30 1:30 1:45 2:00 2:15 4:15 6:157:15 13:15 19:15 1:01:15 14 1:30 1:45 1:45 1:45 2:00 2:15 2:30 4:30 6:307:30 13:30 19:30 1:01:30 15 1:45 2:00 2:00 2:00 2:15 2:30 2:45 4:45 6:457:45 13:45 19:45 1:01:45 16 2:00 2:15 2:15 2:15 2:30 2:45 3:00 5:00 7:008:00 14:00 20:00 1:02:00 17 2:15 2:30 2:30 2:30 2:45 3:00 3:15 5:15 7:158:15 14:15 20:15 1:02:15 18 2:30 2:45 2:45 2:45 3:00 3:15 3:30 5:30 7:308:30 14:30 20:30 1:02:30 19 2:45 3:00 3:00 3:00 3:15 3:30 3:45 5:45 7:458:45 14:45 20:45 1:02:45 20 3:00 3:15 3:15 3:15 3:30 3:45 4:00 6:00 8:009:00 15:00 21:00 1:03:00 21 3:15 3:30 3:30 3:30 3:45 4:00 4:15 6:15 8:159:15 15:15 21:15 1:03:15 22 3:30 3:45 3:45 3:45 4:00 4:15 4:30 6:30 8:309:30 15:30 21:30 1:03:30 23 3:45 4:00 4:00 4:00 4:15 4:30 4:45 6:45 8:459:45 15:45 21:45 1:03:45 24 4:00 4:15 4:15 4:15 4:30 4:45 5:00 7:00 9:0010:00 16:00 22:00 1:04:00 25 4:15 4:30 4:30 4:30 4:45 5:00 5:15 7:159:15 10:15 16:15 22:15 1:04:15 26 4:30 4:45 4:45 4:45 5:00 5:15 5:307:30 9:30 10:30 16:30 22:30 1:04:30 27 4:45 5:00 5:00 5:00 5:15 5:305:45 7:45 9:45 10:45 16:45 22:45 1:04:45 28 5:00 5:15 5:15 5:15 5:305:45 6:00 8:00 10:00 11:00 17:00 23:00 1:05:00 29 5:15 5:30 5:30 5:305:45 6:00 6:15 8:15 10:15 11:15 17:15 23:15 1:05:15 30 5:30 5:45 5:455:45 6:00 6:15 6:30 8:30 10:30 11:30 17:30 23:30 1:05:30 31 5:45 6:006:00 6:00 6:15 6:30 6:45 8:45 10:45 11:45 17:45 23:45 1:05:45 1-hr. 326:00 7:00 7:00 7:00 7:00 7:00 7:00 9:00 11:00 12:00 18:00 1:00:001:06:00 33 7:00 8:00 8:00 8:00 8:00 8:00 8:00 10:00 12:00 13:00 19:001:01:00 1:07:00 34 8:00 9:00 9:00 9:00 9:00 9:00 9:00 11:00 13:00 14:0020:00 1:02:00 1:08:00 35 9:00 10:00 10:00 10:00 10:00 10:00 10:00 12:0014:00 15:00 21:00 1:03:00 1:09:00 36 10:00 11:00 11:00 11:00 11:00 11:0011:00 13:00 15:00 16:00 22:00 1:04:00 1:10:00 37 11:00 12:00 12:00 12:0012:00 12:00 12:00 14:00 16:00 17:00 23:00 1:05:00 1:11:00 38 12:00 13:0013:00 13:00 13:00 13:00 13:00 15:00 17:00 18:00 1:00:00 1:06:00 1:12:0039 13:00 14:00 14:00 14:00 14:00 14:00 14:00 16:00 18:00 19:00 1:01:001:07:00 1:13:00 40 14:00 15:00 15:00 15:00 15:00 15:00 15:00 17:00 19:0020:00 1:02:00 1:08:00 1:14:00 41 15:00 16:00 16:00 16:00 16:00 16:0016:00 18:00 20:00 21:00 1:03:00 1:09:00 1:15:00 42 16:00 17:00 17:0017:00 17:00 17:00 17:00 19:00 21:00 22:00 1:04:00 1:10:00 1:16:00 4317:00 18:00 18:00 18:00 18:00 18:00 18:00 20:00 22:00 23:00 1:05:001:11:00 1:17:00 44 18:00 19:00 19:00 19:00 19:00 19:00 19:00 21:00 23:001:00:00 1:06:00 1:12:00 1:18:00 45 19:00 20:00 20:00 20:00 20:00 20:0020:00 22:00 1:00:00 1:01:00 1:07:00 1:13:00 1:19:00 46 20:00 21:00 21:0021:00 21:00 21:00 21:00 23:00 1:01:00 1:02:00 1:08:00 1:14:00 1:20:00 4721:00 22:00 22:00 22:00 22:00 22:00 22:00 1:00:00 1:02:00 1:03:001:09:00 1:15:00 1:21:00 48 22:00 23:00 23:00 23:00 23:00 23:00 23:001:01:00 1:03:00 1:04:00 1:10:00 1:16:00 1:22:00 49 23:00 1:00:00 1:00:001:00:00 1:00:00 1:00:00 1:00:00 1:02:00 1:04:00 1:05:00 1:11:00 1:17:001:23:00 6-hrs. 50 1:00:00 1:06:00 1:06:00 1:06:00 1:06:00 1:06:001:06:00 1:06:00 1:06:00 1:06:00 1:12:00 1:18:00 2:00:00 51 1:06:001:12:00 1:12:00 1:12:00 1:12:00 1:12:00 1:12:00 1:12:00 1:12:00 1:12:001:18:00 2:00:00 2:06:00 52 1:12:00 1:18:00 1:18:00 1:18:00 1:18:001:18:00 1:18:00 1:18:00 1:18:00 1:18:00 2:00:00 2:06:00 2:12:00 531:18:00 2:00:00 2:00:00 2:00:00 2:00:00 2:00:00 2:00:00 2:00:00 2:00:002:00:00 2:06:00 2:12:00 2:18:00 1-day 54 2:00:00 3:00:00 3:00:00 3:00:003:00:00 3:00:00 3:00:00 3:00:00 3:00:00 3:00:00 3:00:00 3:00:00 3:00:0055 3:00:00 4:00:00 4:00:00 4:00:00 4:00:00 4:00:00 4:00:00 4:00:004:00:00 4:00:00 4:00:00 4:00:00 4:00:00 56 4:00:00 5:00:00 5:00:005:00:00 5:00:00 5:00:00 5:00:00 5:00:00 5:00:00 5:00:00 5:00:00 5:00:005:00:00 Totals 56 4:00:00 4:23:55 4:23:50 4:23:45 4:23:30 4:2315 4:23:004:21:00 4:19:00 4:18:00 4:12:00 4:06:00 4:00:00 Note 1: All times inthis table are presented in the format dd:hh:mm, where “dd”, “hh,” and“mm” are days, hours, and minutes after time 00:00:00. Note 2: The row“Totals” is (1) the total number of intervals (not IST) beingrepresented and (2) the total amount of time represented within thegiven time series.

6.2.5 SubAppendix C: Toolkit Function Specification Template

This example template can be completed for each toolkit function and canbe posted to a common library. The following template items are used inthis template:

-   -   Function Name    -   Function Version and Date    -   Description—narrative description of what is to be performed or        accomplished by the function    -   Block Function Model—input parameters, output parameters, and        actors    -   Pseudo Code Implementation—parametric mathematical model or        function that explains how function is implemented within the        toolkit framework. Reference implementations that instantiate        this named toolkit function should accomplish the algorithm that        is laid out by this pseudo code. If that is for any reason        impossible, another toolkit function should be named and        described.    -   Reference Implementation(s) Available—example implementation        code that instantiates this function. The implementations should        be referenced here in proper, complete citations.    -   Future Improvements—recommend any future improvements that have        been identified for this function.

6.2.6 SubAppendix C: Standard Advisory Output Control Signal

Each toolkit function that models a system of responsive assets isresponsible to advise the system of assets when and to what degree itshould respond. Each such toolkit function should therefore calculate atime series that states a degree of response for each current intervalstart time (IST). The recommendation has been summarized in FIG. 101.

The following advisory signal format can be used as a standard fortoolkit functions. This method accommodates advisory responses frombinary (curtailed vs. normal) to several discrete levels (e.g., responselevel #1, response level #2, . . . ) to a continuum of possibleresponses (e.g., generate at 56% of nameplate capacity for the specifiedinterval).

The advisory signal has been defined as a signed value to allow itsapplication to responsive loads, responsive generation, and energystorage resources. Positive values are used when the recommended controlaction should increase the availability of energy by either increasinggeneration or by reducing load; a negative number is used when therecommended control actions should reduce generation or increase load.

The signal is quite intentionally defined in respect to a byterepresentation. The three most significant bits have been highlighted inFIG. 101 to emphasize that these bits fully represent the eight statesof any asset system that has four levels of response available to it(the additional bit represents charge/discharge direction). These bitsmay therefore be used quite directly by simple assets or asset systemsthat possess limited computational capability.

1. A signed byte value is assumed (e.g., a signed 8-bit representation[−127, 127]). (For symmetry, the value −128 has not assigned. In gatelogic, the use of one's complement interpretation of negative numbersaccomplishes this symmetry and may be advantageous especially forcontrolling very simple, small assets.)

2. Positive values refer to generation [0, 127]; negative values referto load [−0, −127].

3. The toolkit function is responsible to state a response level foreach future interval, consistent with its modeled influences ontransactive signals. If the asset system's number of available responselevels is known with certainty at the time the toolkit function isselected, the toolkit function may prescribe a representation for eachresponse level.

4. The asset system, or alternatively “glue” code between the toolkitfunction and the asset system, is responsible to interpret the advisorysignal. Interpretation of the advisory signal should be made by firstdividing the respective generation or load range by the number ofresponse levels that are available from the responsive asset system.Then the asset system may determine into which of its available levelsthe advisory signal belongs. If a continuum of available responsesexists for this asset system, the full range of the continuum should bemeaningfully applied to the full nameplate rating or total population,such that the signal range is applied to the entire available resourceor load range.

Example #1

Suppose toolkit load function TKLF_1.4 has been selected to model thebehavior of a set of wind turbines. The behaviors of these wind turbinesare not elastic and would therefore not be expected to change theiroperations in respect to transactive control. This toolkit functionshould not calculate and send any advisory control signal to the set ofwind turbines. The set of wind turbines should not expect to receive anyadvisory control signals.

Example #2

A toolkit load function is being designed to model a system of demandresponsive water heaters. The system of water heaters should becurtailed as a group. One of the outputs from the toolkit load functionis designed to be a time series of advisory signals selected from thedomain {0, 127}, which members represent normal and curtailed operation,respectively, for this load. (In certain implementations, and asdiscussed herein, a series of 56 intervals can be used, where eachinterval is defined by its interval start time (IST). See, e.g.,Subappendix A.) The selection of the extreme advisory signals for a loadhaving only two levels is wise because the signals will prescribe areasonable binary response regardless of the capabilities of the assetsystem to which the signal is sent. The curtailable water heater systemlooks for signals in the ranges [0, 63] (normal operation) or [64, 127](curtailed operation). The range [−0, −127] should be ignored (e.g.,normal operation) by this responsive asset system because it can onlycurtail its load; it cannot increase its load in response to transactivecontrol signals.

Example #3

A toolkit load function is created for a small residential batterystorage system that has only three available response levels—fullycharging, resting, and fully discharging. The function should state atime series of advisory signals to the battery system, perhapsspecifying from among a set of three outputs in the set {−127, 0, 127},which represent the three states fully charging, resting, and fullydischarging, respectively. The battery system should be configured toexpect one of three ranges of advisory signals [−127, −64] (charging),[−63, 63] (resting), or [64, 127] discharging.

Example #4

Another toolkit load function is created to model a battery storagesystem, but this function expects to be paired with a battery systemthat can operate through a continuum of responses from fully charging tofully discharging. The function creates advisory signals accordingly atany integer value in the range [−127, 127]. The battery system convertsthese numbers into percentages of its range of charge and dischargerates, which is done easily by dividing through by the integer 127. Forexample, the advisory signal value 26 is converted to 26/127, or 20.5%of its full available discharge rate.

Example #5

The small battery system of Example #3 is paired with the toolkit loadfunction of Example #4. Even though the toolkit function calculates acontinuum of responses, the battery system that has only three availableresponse levels may nonetheless respond sensibly to the advisory signalthat it receives. However, because the asset's responses do not matchthe responses that will have been modeled by the toolkit function, thetoolkit function will not correctly predict the load (and generation)that will be supplied by this battery system.

6.2.7 SubAppendix D: Toolkit Functions

This subappendix lists and describes example toolkit functions that canbe implemented in embodiments of the disclosed technology. Two types oftoolkit functions have been defined:

(1) Resource and incentive toolkit functions—used to capture theinfluences of energy resources and other influences upon the transactivecontrol and coordination system's incentive signal (e.g., the TIS)

(2) Load functions—used to capture the influence of both elastic (e.g.,“responsive”) and inelastic loads on the transactive control andcoordination system's feedback signal (e.g., the TFS).

SubAppendix B provides a template by which the toolkit functionsthemselves and specific reference implementations of the toolkitfunctions should be documented. Thereafter, these toolkit functions maybe selected from a “library” of such available toolkit functions andapplied at any applicable transactive nodes.

The outputs of toolkit functions constitute an interoperability boundaryas the project strives to standardize the information that flows fromthe toolkit functions into the toolkit framework at many levels of aninteroperability information stack.

6.2.8 Resource and Incentive Toolkit Functions

The example resource and incentive toolkit functions listed in Table 28are defined and represent as instantiations of 8. Calculate ApplicableToolkit Resource and Incentive Functions within the toolkit framework.Toolkit functions having the same name and number should share a commonpurpose and same general approach and should promise the same set ofoutputs into the toolkit framework. Versioning may be used for variantsof these functions that differ slightly in approach, in complexity, orby the nature of expected inputs.

In Table 28, an attempt was made to organize the functions by type andlevel. Following this enumeration, Function 1.1.1 would be a specialimplementation of Function 1.1, which is a special implementation ofFunction 1.0.

Each toolkit function should be defined by appropriate documentationfollowing the template in SubAppendix B.

TABLE 28 List of Resource and Incentive Toolkit Functions Name, No. &Where Version Purpose Applied Inputs Outputs 1.0 Imported ElectricalEnergy 1.1 Non- Accommodate Peripheral Current IST Time series ofTransactive importation of transactive time series. energy Importedelectrical nodes that are Historical index exchange P_(G) Energy energyfrom scheduled to at price or cost through this outside this timesreceive information corridor using transactive bulk electrical aboutthis the current set node from energy from exchange, of IST entitiesthat are outside the which can intervals. not themselves boundaries ofinform Time series of transactive this transactive simulation ofpredicted cost nodes-are not control and current energy of energyparticipants in coordination costs for this through this thistransactive system. exchange of corridor C_(E). control and energy.coordination Historical system. energy exchanges for this corridor.Alternatively, seasonally- adjusted daily and weekly exchange schedulesfrom which simulations may be informed and improved. Intertie exchangeschedules (may be estimated from an informed simulation). Price indexthat represents the current delivered cost of electrical energy throughthis exchange corridor if such current information can be obtained. Dayof week and holiday schedules. 1.2 Transactive Converts A transactiveCurrent IST TIS restated Imported transactive node should time series.as energy Energy signals from restate the Transactive terms C_(E .)transactive transactive incentive TFS restated neighbors into signalsthat it signals (TIS) as energy framework receives in from each termsP_(G) for parameter terms of toolkit transactive the intervals outputsthat are framework neighbor. during which expected by the parameters.Transactive the TFS toolkit This toolkit feedback represents framework.function is so signals (TFS) imported basic that it from each energy.may be treated transactive as part of the neighbor. toolkit framework.2.0 Renewable Energy Resource 2.1 Wind Encourage use Applicable toCurrent IST Predicted Energy of wind-farm- energy time series. averagewind scale energy produced by a Historical wind power P_(G) when andnear wind farm. May farm power using intervals where it is be applied tooutput time of the current generated. aggregated series, which IST timeThe cost of output from may be used to series. supplying multiple windtune and refine Infrastructure renewable farms. predictions. cost timeenergy is Use this Actual current series C_(I) using applied as anfunction at wind farm intervals of the infrastructure transactive poweroutput, current IST cost, not as an nodes where which may be timeseries. energy cost, in owners own or used to tune (Infrastructure orderto represent one and refine costs are not encourage the or more windpredictions. expected to be consumption of farms. Predicted windespecially wind energy. Transactive speed and dynamic, but it nodes thatdirection time is specified as have and series. a time series representwind Predicted for farm energy relative humidity consistency.) that istime series. produced Predicted air within their density time electricalseries. boundaries. Predicted resource availability (accounts foreffects of maintenance and curtailment shedding). Function that predictswind farm power output from these conditions. Estimated amortized windfarm infrastructure expense, including operational and maintenanceexpenses, which estimates will be used to state the infrastructureparameter. If the costs of these specific wind farms are unavailable,secondary sources of such estimates may be used. (Infrastructure costsare probably the only costs that will be used by this function, so insome emobdiments, the infrastructure cost can be estimated from thetotal, long- term expense of supplying wind energy from the resource. Bydoing so, the effective cost of the wind energy will be incorporatedover time using a meaningful cost.) 2.2 Solar Encourage use Applicableto Current IST Predicted Energy of solar energy medium- or time series.average solar when and near large-scale Historical solar power P_(G)where it is solar site power using intervals generated. generation.output time of the current The cost of (Small solar series, which ISTtime supplying sites may be may be used to series. renewable better tuneand refine Infrastructure energy is addressed as predictions. cost timeapplied as an negative load Actual current series C_(I) usinginfrastructure toolkit solar site power intervals of the cost, not as anfunctions, output, which current IST energy cost, in especially if maybe used to time series. order to such energy tune and refine(Infrastructure encourage the offsets and predictions. costs are notconsumption of reduces load Predicted solar expected to be solar energy.at this insolation time especially location.) series. dynamic, but itTransactive Predicted wind is specified as nodes where speed and a timeseries owners own direction time for medium- or series. consistency.)large-scale Predicted air solar density time generation. series (may orTransactive may not be nodes that used). have and Predicted representthe resource energy from availability, solar sites which accounts withintheir for maintenance electrical outages. boundaries. Function thatpredicts solar power from these inputs. Estimated amortized solar siteinfrastructure expense, including operational and maintenance expenses,which estimates will be used to state the infrastructure parameter. Ifthe costs of these specific solar sites are unavailable, secondarysources of such estimates may be used. Infrastructure costs are probablythe only costs that will be used by this function, so in someembodiments, the infrastructure cost should be estimated from the total,long- term expense of supplying solar energy from the resource. By doingso, the effective cost of the solar energy will be incorporated overtime using a meaningful cost. 2.3 TBD, based on Transactive Current ISTPredicted Hydropower input expected nodes that own time series. averagefrom a or represent Scheduled hydropower P_(G) hydropower hydropowerhydropower time series working group generation. generation using thethat has been Transactive production intervals of the asked to nodesthat targets current IST formulate this have or Actual time seriesfunction. represent hydropower Predicted Perhaps, hydropower generation,if infrastructure encourage use generation available. cost time ofhydroelectric within their Day of week series C_(I) using energy whenelectrical and holidays. intervals of the and near where boundaries.current interval it is generated. start time (IST) This function series.should at least (Infrastructure represent costs are not federal expectedto be hydropower of especially the region but dynamic, but it shouldstrive to is specified as represent all a time series regional forhydropower. consistency.) 3.0 Fossil Represent Transactive Current ISTPredicted Generation effect of fossil- nodes that own time series.average fuel generation or represent Predicted cost generated onelectrical fossil of fuel, which power P_(G) time energy cost.generation. may be either series using May be used constant or a theintervals of for aggregated dynamic time the current IST sets of fossilseries, time series. generation depending on Corresponding resources.the fuel. predicted Should apply Generator energy costs to fossildispatch of generated generation schedule(s). power C_(E) within theFuel heating using the electrical value (probably intervals of theboundary of a a constant). current IST transactive Plant efficiency timeseries. node. (probably a Predicted constant, but infrastructure may bea cost C_(I) time function of series using generated the intervals ofpower and other the current IST inputs). time series. Outdoor(Infrastructure temperature cost is not time series. expected to beInput feed especially temperature dynamic, but it time series. isspecified as Representative a time series amortized for infrastructureconsistency.) cost. (In some cases, the infrastructure costs will bestated as functions of many variables, including local costs of money,taxes, regulations, etc.) Function by which inputs are used to predictpower output. Day of week and holidays. 4.0 General Represent bulkAlmost every TBD. Estimate Infrastructure Infrastructure influence oftransactive of present cost time Cost infrastructure node could useinfrastructure series C_(I). investments on this function. valueamortized delivered cost over an of electrical applicable energy whereit horizon. might be Calculation impracticable to should include trackindividual effects of local infrastructure influences like a components.utility's normal estimate of useful equipment lifetime. Estimates shouldbe calibrated against known ways in which long-term infrastructure costsare addressed. 5.0 System Constraints 5.1 Discourage TransmissionPredicted Capacity cost Transmission consumption zone flowgate power.C_(C) and Flowgate downstream transactive Formula by corresponding from,and nodes on which flowgate flowgate encourage either side of a powerwill affect capacity P_(C). consumption flowgate. TIS each upstreamfrom, transactive a flowgate node. transmission Additional constraint.inputs may be Costs should be considered for grounded future versions,somehow in but the initial actual costs version should that would be bekept very incurred if simple. flowgate constraints were to be violated.5.2 Equipment Discourage Transactive Predicted Predicted and Lineconsumption of nodes that are capacity to capacity cost Constraintsenergy in a position to which this time series C_(C) downstream mitigatetheir function applies. and from constraints by Function whichcorresponding constrained increasing the estimates the capacity timedistribution delivered cost cost impacts of series P_(C). equipment, ofenergy to exceeding the including downstream capacity distributiontransactive constraint. lines. nodes. Intended to be used whereconstraints may be correlated to specific equipment. Does not apply totransmission flowgates. 6.0 System Energy Losses 6.1 Incorporate thePresently a low Function by Lost energy Transmission effect of linepriority. which TFS and term of type Losses losses on cost Intended fornon-transactive P_(G). of delivered application in imported and energyin transmission exported power transmission zones. indicate long- zonesMay be distance defined and transmission applied for losses across amajor transmission transmission zone. across Representative transmissionfraction of zone transmitted transactive power to be nodes. lost, whichmay be applied as a representative resistance at a stated transmissionvoltage. 6.2 Distribution Incorporate the Presently a low Function byLost energy Losses effect of line priority. which TFS and term of typelosses on cost Intended for non-transactive P_(G). of deliveredapplication in imported and energy in the topology at exported powerdistribution and locations other can be used to other locations thandefine energy where specific transmission losses in lossy zones.specific equipment can Applied where equipment or be identified. lossesmay be systems. Reflects that attributed to the value of specificdissipated equipment or energy is lost. systems. 7.0 Demand Charges 7.1BPA Utility Subproject Predicted Capacity time Demand transactivetransactive capacity to series P_(C) that Charges node takes nodes wherewhich demand causes the steps to owners are charges may demand managepeak utilities that are apply. charges. loads that may subject toHistorical utility Capacity cost incur demand demand load during thetime series C_(C) charges. charges from current month, that Help autility BPA. including prior corresponds to reduce its peak hour. thecapacities. monthly peak. Function by (The which cost capacities impactof may, or may capacity may be not, also be predicted. TFS values, Dayof week depending on and holidays. the boundaries of a given transactivenode.) 7.2 Seattle City This function UW's SCL peak Average power LightDemand predicts the transactive demand rate capacity P_C Charges impactof node. [$/kW] as defined by demand SCL off-peak the charges that thedemand rate Transactive Seattle City [$/kW] Node Light (SCL) willTransactive Framework apply to the Feedback [kW]. University of Signal(TFS) Capacity cost Washington [kW] C_C as (UW) Interval Start definedby the Times (ISTs) Transactive A scaling factor Node K by which theFramework effect of the [$/kW]. demand charges may be scaled. 8.0 MarketImpacts 8.1 Spot Utility Subproject TBD. TBD. Market Impacts transactivetransactive Perhaps, Perhaps, node takes nodes where predicted capacitytime steps to owners are capacity to series P_(C) that mitigateutilities that are which spot causes the (optimize) the subject to themarket impacts spot market predicted impacts of spot may apply. impactsand impacts that it market trading. capacity cost will likely incur timeseries C_(C) on spot that markets. corresponds to the capacities. Thisfunction might use other cost time series C_(O) if it cannot be statedin terms of energy, capacity, or infrastructure.

6.2.9 Load Toolkit Functions

Load toolkit functions are instantiated as 6. Calculate ApplicableToolkit Load Functions within the toolkit framework. The load beingdescribed by these functions may be either elastic (responsive to theTIS) or inelastic (not responsive to the TIS). These functions shouldnot have direct influence and effect on the calculation of TIS as thistransactive node; functions that will affect the formulation of TISshould be stated as resource or incentive toolkit functions.

The Demonstration attempts to define and use a minimum adequate set ofload toolkit functions. Therefore, implementers should select and applythe most general function that can describe the expected behaviors. InTable 29, an attempt was made to organize the functions by type andlevel. Following this enumeration, Function 1.1.1 would be a specialimplementation of Function 1.1, which is a special implementation ofFunction 1.0. Function 1.0 is more general that is the Function 1.1under it.

The most general functions have been stated as

1. Bulk inelastic load—large sets of load that is not affected by theTIS

2. General event-driven demand response (DR)—sets of asset systems thatare infrequently affected by the TIS. These asset systems are affectedin a binary, on/off way or occasionally provide a limited number ofdiscrete response levels. Specific examples may include distributionvoltage control, water heater programs, smart appliance programs, anddistributed generation.

3. General time-of-use (TOU) DR—sets of asset system that are affectedby the TIS according to a daily cycle. These asset systems are affectedin a binary, on/off way or occasionally provide a limited number ofdiscrete response levels. Examples may include distribution voltagecontrol, water heater programs, smart appliance programs, and batterystorage.

General real-time (RT) DR—sets of asset systems that are affected by theTIS and employ a continuum of possible responses. Examples may includeenergy portals and battery storage.

TABLE 29 List of Load Toolkit Functions Name, No. & Where VersionPurpose Applied Inputs Outputs 1.0 Bulk Predict bulk, TransactiveCurrent IST time Predicted Inelastic undifferentiated nodes whereseries. inelastic load Load inelastic it is preferred (LI_01) Historicalfor each load in the to predict load for this current IST most generalundifferentiated modeled interval. sense. bulk load. population Placeswhere (LI_02) Present specific load (average models to power) for thispredict the population of behaviors of inelastic load differentiated(LI_03) load Predicted components outdoor are not temperature timepossessed. series Nearly every (LI_04) subproject Predicted could usethis insolation time function. series (LI_05) Predicted wind speed anddirection time series (LI_06) Weekday, weekend day, and holidayindicator (LI_08) Typical seasonally- adjusted daily load profile(LI_07) Average daily load (a constant for the prediction horizon) 1.1Bulk Predict the Transactive Current IST time Predicted Commercial loadof bulk nodes that series. inelastic load Load inelastic represent(LI_01) Historical for each commercial inelastic load current IST load.May be electrical load (LI_02) Actual interval. used to from measuredload represent aggregated (LI_03) sets of commercial Predictedaggregated loads. outdoor commercial Most temperature time loads, evensubproject series ones with transactive (LI_04) diverse nodes will usePredicted membership. this function. insolation time Does not seriesmodel (LI_05) underlying Predicted wind commercial speed and buildingsand direction time processes. series This model (LI_06) Day of does notweek and include holidays elastic (LI_07) Average behaviors daily loadthat would (constant during be expected the prediction to respond tohorizon) a TIS. (LI_08) Typical daily load profile 1.2 Bulk Predict theTransactive Current IST time Predicted Industrial load of bulk nodesthat series. inelastic load Load industrial represent (LI_01) Historicalfor each load types. electrical load load current IST Does not from(LI_02) Actual interval. model aggregated measured load underlyingindustrial (LI_03) industrial loads. This Predicted processes. functiondoes outdoor not require temperature time underlying series industrial(LI_04) processes to Predicted be understood insolation time andmodeled. series May be (LI_05) applied to Predicted wind multiple speedand aggregated direction time industrial series loads. (LI_06) Day ofMany week and subproject holidays transactive (LI_07) Average nodes thatdaily load (a include constant during industrial the prediction loadsmay horizon) choose to use (LI_08) Typical this function. daily loadprofile (LI_09) Fractional representation of common commercial buildingtypes 1.3 Bulk Predict the Transactive Current IST time PredictedResidential load of bulk nodes that series. inelastic load Loadresidential wish to (LI_01) Historical for each load type. representload current IST Predict load electrical load (LI_02) Actual interval.of residential for groups of measured load feeders or residences (LI_03)groups of like those on Predicted residential residential outdoorfeeders. feeders. temperature time Does not Applied to seriesnecessarily residential (LI_04) model loads that are Predictedindividual not insolation time residences responsive to series or thethe TIS (e.g., (LI_05) underlying inelastic Predicted wind behaviors ofresidential speed and homes and populations). direction time theirIndividual series occupants. residences (LI_06) Day of Models and weekand inelastic underlying holidays residential resident (LI_10) Numberload only. behaviors are of single- and not modeled. multiple-familyAlmost every units subproject transactive node is expected to use thisfunction for its residential customers who do not respond elastically.1.4 Small Predict the Locations that Current IST time Time series Wind“negawatts” host relatively series. output power Generator to be smallwind (LI_11) Historical for each IST Negative produced by generators orpower interval. This is Load small wind wind sites that production timean inelastic energy primarily series load resources. offset a larger(LI_12) component This function electrical load. Predicted wind becauseit is is preferred speed and not a function where a direction time ofthe TIS. relatively series for a No control small representative outputis sent amount of tower height to renewable wind (LI_13) Historicalgenerators. renewable wind speed and Renewable generation direction at agenerators are offsets load representative not responsive at a location.tower height to the If the energy near the wind transactive from a windgeneration control and energy (LI_14) coordination resource Measuredwind system. should affect speed and TIS at this direction at a andrepresentative electrically tower height downstream near the locations,the generation site energy from (LI_15) Historical this resourcerelative humidity should be time series incorporated (LI_16) with aPredicted resource and relative humidity incentive time series toolkit(LI_17) Historical function air density time instead (See series Table28:). (LI_18) Predicted air density time series (LI_X) Effective totalcross- sectional area (LI_X) Wind conversion efficiency curve (LI_19)Season, or day of year (LI_20) Total nameplate or “typical” powercapacity (LI_X) Predicted resource availability 1.5 Small- Predict andLocations that Current IST time Time series Scale represent hostrelatively series. output power Distributed “negawatts” small fossil(LI_01) Historical for each IST Generator load from fuel power interval.Negative one or more generators production Distributed Load relativelythat are not (IL_X) Resource generators of small influenced in schedulethis toolkit distributed their operation (LI_20) function are generatorsby the TIS. Nameplate or not responsive that target power to the consumeproduction transactive hydrocarbon magnitude. control and fuels at this(LI_6) Day of coordination location. week and system, but These holidaysthey may generators (LI_IX) Predicted respond to are not resource otherpurposes influenced by availability and objectives the TIS. of theirowners If the (e, g., periodic influence of maintenance a distributedschedules, generator feedstock should availability). No directly affectcontrol output the TIS at a is sent to these transactive distributednode, select generators. an appropriate source and incentive toolkitfunction from Table 28:. 1.6 Small- Predict the Locations that CurrentIST time Time series Scale Solar “negawatts” host relatively series.average output Generator to be small solar (LI_01) Historical power foreach Negative produced by generators power IST interval. Load smallsolar that primarily production No control energy offset a larger(LI_??) Historical output is sent resources. electrical load. insolationtime to renewable This function series generators. is preferred (LI_04)Renewable where a Predicted generators are relatively insolation timenot responsive small series to the amount of (LI_??) Historicaltransactive solar wind speed and control and renewable direction timecoordination generation series system. offsets load (LI_05) at alocation. Predicted wind If the energy speed and from a solar directiontime energy series. resource (LI_15) Historical should affect relativehumidity TIS at this time series and (LI_16) electrically Predicteddownstream relative humidity locations, the time series. energy from(LI_17) Historical this resource air density time should be seriesincorporated (LI_18) with a Predicted air resource and density timeincentive series toolkit (LI_19) Monthly function typical energy instead(See (LI_20) Total Table 29). nameplate or “typical” power capacity(LI_??) Predicted resource availability (LI_??) Solar ConversionEfficiency Curve 2.0 General Most general Applicable to Current IST timePredicted Event-Driven function for many series. inelastic load Demandpredicting responsive Recent history at for each IST Response the assetsystems (e.g., 1 day to 1 interval. behaviors of that conduct week) ofTIS that Predicted responsive traditional may be used if change in loadassets demand relative TIS is to elastic load for that only response betracked in a each IST infrequently several times statistical sense.interval. respond. a month. (LI_01) Historical When these Response loadtime series assets may (LI_02) Actual respond they additionally measuredload change define a TIS time series. between a “critical” (LI_??)Device very limited response count number of level for (LI_06) Day ofavailable extreme week and response conditions. holidays levels. (LI_08)Daily It is load profile postulated (L1_28) Minimum that this eventduration function can (LI_29) be designed Promised event flexibly tocount or respond to frequency that absolute or has been relative TISnegotiated with as desired customers. by the (LI_30) application.Limitations on event duration that have been promised to customers. 2.1Represent Asset Current IST time Predicted Commercial especially systemssuch series. inelastic load Event-Driven the change as See 1.1 Bulk atfor each IST Demand in elastic thermostats, Commercial interval.Response response water heaters, Loads. The Predicted from and HVACs.inputs that have change in commercial been defined for elastic load forentities that function 1.1 Bulk each IST are Commercial interval.performing Loads are again Predicted time lighting, used to predictseries of space the inelastic load output advisory conditioning,component of control signals. or other the commercial See control ofload to be SubAppendix commercial modeled by this C. (Default buildings.function. expects two Additionally, the load levels following inputsspecified by may be used to the domain {0, model the 127}). The setchange in elastic of output load: signals may be TIS time series.parametrically Recent history modified based (e.g., 1 day to 1 on thenumber week) of TIS that of available may be used if response relativeTIS is to levels, a static be tracked in a input. statistical sense.(LI_??) Device Count (LI_29) Promised event count or frequency that hasbeen negotiated with customers. (LI_30) Limitations on event durationthat have been promised to customers. (LI_31) Representative unitchanges in power that will occur at prescribed response levels. (LI_??)Number of response levels available from asset system. 2.2 Event- To beused Many Current IST time Predicted Driven where subproject series.inelastic load Distribution subprojects locations of (LI_01) Historicalat for each IST System of the the load interval. Voltage DemonstrationDemonstration TIS time series. Predicted Control have that (LI_32)Present change in offered to implement actual voltage elastic load formodulate conservation regulation level each IST distribution voltageCurrent IST time interval. system regulation series Predicted timevoltage in (CVR) or (LI_35) series of response to voltage Implementer'soutput advisory relatively optimization criteria control signals.extreme and have concerning how See conditions of offered to often andhow SubAppendix the TIS. This make system long voltage may C. (Defaultfunction voltage be affected at expects two should responsive to eachlevel. Note load levels include the the TIS. that this input specifiedby option where may probably be the domain {0, the degree of adequately127}). The set voltage represented by of output change is input typessignals may be affected by LI_29 and LI_30. parametrically feedback(LI_36) Day-long modified based from hourly time on the numbermeasurements series of relative of available of voltage fractions ofload response at various that are constant levels, a static feederimpedance, input. locations. constant current, Regardless, and constantutilities power, should keep respectively customer (LI_??) Numbervoltage of response within levels available accepted from asset ranges.system. 2.4 Asset See 1.3 Bulk Predicted Residential systems.Residential inelastic load Event-Driven Load. The at for each IST Demandinelastic interval. Response residential load Predicted component maychange in use the same elastic load for inputs as were each IST used forfunction interval 1.3 Bulk Predicted time Residential series of Load.output advisory The following control signals. additional inputs See maybe used to SubAppendix predict changes C. (Default in the elasticexpects two load component: load levels TIS time series specified byCurrent IST time the domain {0, series 127}). The set (LI_20) Total ofoutput nameplate or signals may be “typical” power parametricallycapability (of modified based devices to be on the number curtailed) ofavailable (LI_??) Hourly response curtailable power levels, a static(LI_??) Device input. count (LI_28) Minimum Event Duration (LI_29)Promised Event Count or Frequency (LI_30) Limitations on CurtailmentEvent Duration (LI_31) Representative Changes in Power at PrescribedResponse Levels (LI_??) Actual Number of Times that Actuation hasAlready Occurred in each Relevant Time Period (LI_??) Actual durationthat actuation has already occurred in each relevant time period (LI_??)Number of response levels available from asset system. 2.5 Non- Asset(LI_01) Historical Predicted Renewable systems. Load or inelastic loadDistributed Generation at for each IST Generation (LI_02) Actualinterval. Event-Driven Measured Load Predicted Demand or Generationchange in Response (LI_06) Day of elastic load for Week and each ISTHoliday interval (LI_07) Average Predicted time Daily Load or series ofGeneration output advisory (LI_08) Daily control signals. Load or SeeGeneration SubAppendix Profile C. (Default (LI_19) Monthly expects twoTypical Energy load levels (LI_??) specified by Resource the domain {0,Schedule 127}). The set TIS time series of output (LI_??) Device signalsmay be Count parametrically (LI_20) Total modified based nameplate or onthe number “typical” power of available capability (of response devicesto be levels, a static curtailed) input. (LI_??) Hourly curtailablepower (LI_??) Device count (LI_28) Minimum Event Duration (LI_29)Promised Event Count or Frequency (LI_30) Limitations on CurtailmentEvent Duration (LI_31) Representative Changes in Power at PrescribedResponse Levels (LI_??) Actual Number of Times that Actuation hasAlready Occurred in each Relevant Time Period (LI_??) Actual durationthat actuation has already occurred in each relevant time period (LI_??)Number of response levels available from asset system. 3.0 General Mostgeneral Applicable at See function 1.0 Predicted Time-of-Use functionfor locations that Bulk Inelastic inelastic load Demand predicting hostsimple Load. The inputs at for each IST Response responsive DR systemsfrom 1.0 Bulk interval. load that should Inelastic Load Predictedbehaviors of respond daily. are also useful change in groups of by thisfunction elastic load for devices that for predicting the each ISTrespond to inelastic load interval. diurnal component. Predicted timevariability in Additionally, the series of the TIS (e.g., followinginputs output advisory respond to will be useful for control signals.one or more the prediction of See daily changes in SubAppendixintervals) elastic load C. (Default component: expects two TIS timeseries load levels (LI_??) Device specified by Count the domain {0,(LI_28) Minimum 127}). The set Event Duration of output (LI_29) signalsmay be Promised Event parametrically Count or modified based Frequencyon the number (LI_30) of available Limitations on response Curtailmentlevels, a static Event Duration input. (LI_31) Representative Changes inPower at Prescribed Response Levels (LI_??) Actual Number of Times thatActuation has Already Occurred in each Relevant Time Period (LI_??)Actual duration that actuation has already occurred in each relevanttime period (LI_??) Hourly Unit Expected Change in Power at Event Levels(LI_??) Number of response levels available from asset system. 3.1Battery Represent Locations that (LI_01) Historical Predicted Storage-behaviors of host usually Load or inelastic load Time-of-Use batterysmall battery Generation at for each IST storage systems (LI_02) Actualinterval. This systems that controlled Measured Load will normally areengaged simply on a or Generation be zero, with a daily diurnal (LI_20)Total assuming that pattern, pattern. Nameplate or the battery usuallyto Presently, no “Typical” Power charges and mitigate daily transactiveCapacity discharges peak. Battery nodes claim (LI_??) Device only for isfully to be applying Count economic charging, battery (LI_28) Minimumreasons and fully systems in Event Duration according to discharging,this way. (LI_29) the condition of or resting. Promised the TIS signal.Maximum Event Predicted Count or change in Frequency elastic load for(LI_30) each IST Limitations on interval. Maximum Event Predicted timeDuration series of (LI_31) output advisory Representative controlsignals. Changes in See Power at SubAppendix Prescribed C. (DefaultResponse expects three Levels load levels (LI_??) Actual specified byNumber of the domain {−127, Times that 0, 127}). Actuation has The setof Already output signals Occurred in may be each Relevantparametrically Time Period modified based (LI_??) Actual on the numberduration that of available actuation has response already occurredlevels, a static in each relevant input. time period (LI_41) PredictedResource Fractional Availability Current IST time series. TIS timeseries. (LI_??) Battery state of charge. (LI_??) Useful Energy StorageCapacity (LI_??) Number of response levels available from asset system.3.2 Represent Transactive See 1.1 Bulk Predicted Commercial effects ofnodes that Commercial inelastic load Time-of-Use predominantly offerLoads. This at for each IST Demand commercial commercial function mayuse interval. Response lighting and system the same inputs Predictedspace responses for as function 1.1. change in conditioning addressingBulk Commercial elastic load for programs daily peak. Loads as it eachIST that respond predicts the interval. to one or inelastic Predictedtime several daily component of its series of peak load. output advisoryperiods. These additional control signals. inputs may be See used tocalculate SubAppendix the change in C. (Default the elastic expects twocomponent of load levels this function's specified by load: the domain{0, TIS time series. 127}). The set (LI_??) Device of output Countsignals may be (LI_28) Minimum parametrically Event Duration modifiedbased (LI_29) on the number Promised Event of available Count orresponse Frequency levels, a static (LI_30) input. Limitations onCurtailment Event Duration (LI_31) Representative Changes in Power atPrescribed Response Levels (LI_??) Actual Number of Times that Actuationhas Already Occurred in each Relevant Time Period (LI_??) Actualduration that actuation has already occurred in each relevant timeperiod (LI_??) Hourly Unit Expected Change in Power at Event Levels(LI_??) Number of response levels available from asset system. 3.4Predict and Applied where See 1.3 Bulk Predicted Residential representprogrammable, Residential inelastic load Time-of-Use responsecommunicating Load. This at for each IST Demand from thermostats;function may use interval. Response automated smart the same inputsPredicted residential appliances, as for 1.3 Bulk change in demand-demand- Residential Load elastic load for response response to predictthe each IST systems of switch units, inelastic interval. many types orother component of its Predicted time that will assets are load. seriesof respond installed in The following output advisory approximatelyresidences additional inputs control signals. daily to and where may beused to See help mitigate programs are predict the SubAppendix peakdesigned to change in elastic C. (Default conditions. have these load:expects two This function systems TIS time series. load levels appliedto respond to (LI_??) Device specified by automated daily peak Count thedomain {0, responses periods. (LI_28) Minimum 127}). The set and mayAsset Event Duration of output accommodate systems such (LI_29) signalsmay be customer as water Promised Event parametrically opt-out. heatercontrol, Count or modified based thermostat Frequency on the number loadcontrol. (LI_30) of available Limitations on response Curtailmentlevels, a static Event Duration input. (LI_31) Representative Changes inPower at Prescribed Response Levels (LI_??) Actual Number of Times thatActuation has Already Occurred in each Relevant Time Period (LI_??)Actual duration that actuation has already occurred in each relevanttime period (LI_??) Hourly Unit Expected Change in Power at Event Levels(LI_??) Number of response levels available from asset system. 3.5Time-of- Similar to Applicable Current IST time Predicted Use toolkitwhere voltage series. inelastic load Distribution function 2.2, iscontrolled Historical power at for each IST System except at two or moreconsumption interval. Voltage voltage may levels TIS time series.Predicted Control be controlled according to TIS threshold(s), change inaccording to the value of which may elastic load for daily on- and theTIS and further be each IST off-peak other inputs parametricallyinterval. periods. and where affected. Predicted time responses of(LI_??) Number series of the asset of response output advisory have beenlevels available control signals. designed to from asset See occursystem. SubAppendix according to C. (Default daily on-and expects twooff-peak load levels periods. specified by the domain {0, 127}). The setof output signals may be parametrically modified based on the number ofavailable response levels, a static input. 3.6 Time-of- Asset See 3.1Battery Predicted Use Electric systems such Storage-Time- inelastic loadVehicle as vehicle of-Use. This at for each IST Charging charging.function is interval. expected to use Predicted the same inputs changein as does 3.1 elastic load for Battery each IST Storage-Time- intervalof-Use. Predicted time Additionally, series of these inputs may outputadvisory be used control signals. because of the See special SubAppendixcharacteristics of C. (Default electric vehicles: expects two (LI_??)Time at load levels Which Energy specified by Storage Should the domain{0, be Fully 127}). The set Charged of output (LI_??) Number signals maybe of response parametrically levels available modified based from asseton the number system. of available response levels, a static input. 3.7Non- This function Asset Maximum Predicted Renewable predicts thesystems. allowed rate of inelastic load Distributed response change in(generation) Generation from a non- generated power from this assetTime-of-Use renewable Number of system Demand distributed responselevels Predicted Response generator to be prescribed average demand- forthis asset change in response system elastic load for system thatTypical fraction each IST will respond of time that each intervalapproximately response level/ Predicted time daily to should be activeseries of help mitigate during a day output advisory peak Minimum timecontrol signals. conditions duration for See that are which an eventSubAppendix evident in an level/should C. (Default incentive remain inforce expects two signal. for this day type load levels after it hasspecified by become initiated the domain {0, Maximum total 127}). Theset event duration of output permitted per signals may be day type andper parametrically event allowed for modified based each event on thenumber level/ of available Limitations on response the minimum levels, astatic number of TOU input. events that may be called during the threemajor day types for each response level/ Limitations on the maximumnumber of TOU events that may be called during the three major day typesfor each response level/ Recent history of TIS Current TIS for futureIST intervals Typical baseline power that is generated during UTC hour hof a weekday day type by this distributed generation resource Typicalbaseline power that is generated during hour h of a weekend day by thisdistributed generation resource Change in generation that may beanticipated at each of the L response levels 4.0 General Most generalApplicable at Current IST time Predicted Real-time function forlocations that series. inelastic load Continuum predicting host simpleHistorical power at for each IST Demand responsive RT systems.consumption interval. Response load TIS time series. Predicted behaviorsof Parametric change in groups of algorithm by elastic load for devicesthat which change in each IST respond elastic load may interval.according to be predicted. Predicted time a continuum series of ofpossible output advisory responses. control signals. See SubAppendix C.(Default expects a continuum of advisory levels [0, 127]). 4.1 BatteryPredict and Applicable to Current IST time Predicted Storage- representthe battery series. inelastic load Real-Time response storage Historicalpower at for each IST and systems that consumption, interval. conditionof respond very generation Predicted a battery dynamically to patternschange in system is the TIS and TIS time series. elastic load for highlyother local Parametric each IST responsive conditions algorithm byinterval. to the and provide which change in Predicted time dynamic alsoa elastic load may series of changes in continuum of be predicted.output advisory the TIS and charge and State of charge. control signals.that discharge Limitations on See responds levels. maximum SubAppendixusing a Asset charge and C. (Default continuum of systems such dischargelevels. expects a charge and as Demand continuum of discharge Shiftersand advisory levels levels. distribution [−127, 127]). batteries. 4.2Predict and Mostly Current IST time Predicted Commercial representapplicable to series. inelastic load Real-Time dynamic commercialHistorical power at for each IST Demand commercial space heatingconsumption interval. Response demand- but may be TIS time seriesPredicted response applicable to Parametric change in systems that otheralgorithm by elastic load for observe the commercial which change ineach IST full dynamics devices that elastic load may interval. of theTIS observe the be predicted Predicted time (and other full dynamicsseries of information) of the TIS output advisory and (and other controlsignals. dynamically information) See respond and respond SubAppendixusing a with a C. (Default continuum of continuum of expects a possiblepossible continuum of control control advisory levels outcomes. outcomes[0, 127]). (e.g., temperature settings). 4.3 Real- Asset Predicted Timesystems. inelastic load Distribution at for each IST System interval.Voltage Predicted Control change in elastic load for each IST intervalPredicted time series of output advisory control signals. SeeSubAppendix C. (Default expects a continuum of advisory levels [0,127]). 4.5 Predict and Applicable Current IST time Predicted Residentialrepresent where series. inelastic load Real-Time responses residentialHistorical power at for each IST Demand from the customers consumptioninterval. Response most possess TIS time series Predicted dynamic ofspace Parametric change in residential conditioning algorithm by elasticload for demand- systems that which change in each IST response observethe elastic load may interval. system that dynamics of be predictedPredicted time observe the the TIS and Day and time of series ofdynamics of provide a day output advisory the TIS (and continuum ofcontrol signals. other responses. See information) Asset SubAppendix andsystems. C. (Default automatically expects a respond with continuum ofany of a advisory levels continuum of [0, 127]). possible responses. 5.0General (LI_??) Number Predicted Manual or of response inelastic loadBehavioral levels available at for each IST Demand from asset interval.Response system. Predicted change in elastic load for each IST interval.Predicted time series of output advisory control signals. SeeSubAppendix C. (Default expects a continuum of advisory levels [0,127]). 5.1 Special case Applicable Current IST time PredictedResidential of toolkit load where series. inelastic load Behavioralfunction 5.0 residential Prediction of the at for each IST Response towhere the customers inelastic load interval. Portals or In- means ofhave been output may use Predicted Home conveying provided in- the sameinputs change in Displays demand- home displays as were elastic load forresponse or portals that described for each IST information display thefunction 1.0 Bulk interval. or requests TIS. Inelastic Load. Variant #1-to residents Asset Refer to that continuum: is either an systems.function. Where Current TIS in-home the load is signal is display orpredominantly relayed to the energy residential, portal or in- portal.An commercial, or home display. energy portal industrial, the Variant#2- or in-home- designer should discrete levels: display is a refer tothe Predicted time dedicated respective series of piece of functions1.1, output advisory equipment 1.2 or 1.3. control signals for the Thefollowing are sent to in- conveyance additional inputs home display ofdemand- are used to or portal that response predict the conveyinformation change in elastic discrete or advice. load: response The TIStime series. levels for actuation of (LI_??) Number events or timeenergy of response of use periods. responses is levels available See notfrom asset SubAppendix automated system. C. (Default by this expects twofunction, but load levels the means specified by by which the the domain{0, customer is 127}). The set informed or of output advised signals maybe should be parametrically automated. modified based on the number ofavailable response levels, a static input. 5.2 Predict and LocationsCurrent IST time Predicted Residential represent where series. inelasticload Behavioral elastic humans are (LI_??) Number at for each ISTResponse - response informed of response interval. No Portals or fromassets about extreme levels available Predicted In-Home that both usepower grid from asset change in Displays human events and system.elastic load for decisions are invited to each IST and action takeactions interval. but do not that would Variant #1- use energy mitigatethe continuum: portals or in- events. Current TIS home signal isdisplays to relayed to the convey portal or in- demand- home display.response Variant #2- information discrete levels: or requests. Predictedtime series of output advisory control signals are sent to in- homedisplay or portal that convey discrete response levels for events ortime of use periods. See SubAppendix C. (Default expects two load levelsspecified by the domain {0, 127}). The set of output signals may beparametrically modified based on the number of available responselevels, a static input. 5.3 Manual Asset (LI_??) Number PredictedCommercial Systems. of response inelastic load Demand levels availableat for each IST Response from asset interval. system. Predicted changein elastic load for each IST interval. Predicted time series of outputadvisory control signals. See SubAppendix C. (Default expects two loadlevels specified by the domain {0, 127}). The set of output signals maybe parametrically modified based on the number of available responselevels, a static input. 5.4 Manual Predictive Asset Current IST timePredicted Non- advisory systems. series. inelastic load Renewablesignals TIS time series. (generation) at Distributed should be (LI_37)for each IST Energy formulated Frequency or interval. Resources andnumber of times Predicted Demand conveyed to that the DER change inResponse operations may be elastic load personnel at actuated. Note:(generation) Lower Valley this input should for each IST and be replacedby interval. University of more general Variant #1- Washington. LI_29.continuum: The (LI_29) Current TIS operations Promised event signal ispeople will count or relayed to the then frequency that portal or in-manually have been home display. schedule negotiated with Variant #2-and/or customer discrete levels: control their (LI_??) Number Predictedtime distributed of times that series of generation actuation has outputadvisory Resources already occurred control signals correspondingly. ineach relevant are sent to in- time period. home display (LI_??) Actualor portal that duration that convey actuation has discrete alreadyoccurred response in each relevant levels for time period. events ortime- Note: Should of-use periods. replace this input See with moreSubAppendix general LI_30. C. (Default (LI_30) expects two Limitationson load levels curtailment specified by event duration the domain {0,that have been 127}). The set promised to of output customer signals maybe Note: this input parametrically should be modified based replaced bythe on the number more general of available LI_30. response Note: Thislevels, a static should be input. replaced by LI_20, which shares thesame meaning. (LI_20) Total Nameplate or “Typical” Power Capacity.(LI_41) Limitations on operator ability to receive and scheduleresponses. (LI_??) Number of response levels available from assetsystem.

6.3 Appendix C—Collected Set of Example Toolkit Functions

This section introduces a variety of exemplary load and incentivefunctions, any one or more of which can be used in embodiments of thedisclosed technology (e.g., in a toolkit library).

The functions described below should not be construed as limiting in anyway, and are example implementations of functions that can be used in atransactive control and coordination system. Further, the equations,tables, and subappendices in the function descriptions below will havetheir own independent numbering and labeling conventions. Still further,in some instances, some information may be omitted from certainfunctions but could be implemented by those skilled in the art.

6.3.1 Bulk Inelastic Load—N-Day Moving Window (Function 1.01)

Description:

The following is the foundation of an alternative toolkit function to1.0 Bulk Inelastic Load. However, this functional specification can beimplemented with initial measurements over only two prior days, expectsless mathematical knowledge by implementers, is easily documented downto requisite steps, and, for these reasons, may be more amenable toimplementation by some utility implementers.

The basic approach is as follows: For a given circuit location, pairs ofelectrical load and ambient temperature are measured each hour. Datafrom the same hour-of-day and from a comparable day type, for a windowof a chosen number of days, are used to compute the coefficients of alinear model. This model is then used to predict electrical load at thislocation for the same future day type and hour-of-day based on theforecasted ambient temperature for the future hour.

Block Input/Output Function Model:

Inputs:

-   -   {P_(d,h), T_(d,h)}—[kW, ° C.]—paired measurements of actual        electrical power (load) and ambient temperature for a given day        d of a given type (weekday or weekend/holiday) and hour h of the        day at a circuit location. h=0, 1, . . . , 23. These        measurements taken each hour allow the recursive model to become        updated for the respective day type and hour-of-day.    -   N—[dimensionless]—number of days in the moving window that will        be used in the model formulation. Default: 10 (e.g., about two        weeks of weekdays or about a month of weekend/holiday days).    -   T_(f_d,h)—[° C.]—forecasted temperature for a given future        hour-of-day h for a least the next four days (e.g., the        predicted time horizon of the transactive signals). This        forecasted temperature is the input to the model by which        electrical power load may be predicted for a given hour-of-day        and day type.

Interim Calculation Products:

-   -   a_(0_h), a_(1_h)—[kW, kW/° C.]—a set of coefficients that model        a best-fit prediction of electrical power from a forecasted        ambient temperature for a given hour-of-day on a given type of        day.    -   A_(00_h), A_(01_h), A_(11_h), b_(0_h), b_(1_h)—set of five        unique vector and matrix elements that should be stored for each        hour-of-day for each day type. These elements are updated each        time a new pair of load and temperature measurements become        available for the respective hour-of-day and day type.    -   {circumflex over (P)}_(d,h)—[kW]—predicted load for each future        hour for the next four days. These are the outputs from the        linear model for the respective future hour-of-day and day type,        given the forecasted ambient temperature for that future hour.

Outputs:

-   -   L_(inelastic_n)—[kW]—predicted load corresponding to the n^(th)        interval. This is the hourly predicted load {circumflex over        (P)}_(d,h) allocated accordingly to each n^(th) interval.

Pseudo Code Implementation:

-   -   1. For d available measurements, calculate A_(00_h), A_(01_h),        A_(11_h), b_(0_h), and b_(1_h). At startup, two measurements        (e.g., d=2) may be adequate. More prior measurements are        preferred and may be used. It should be pointed out that        singularity is unavoidable when d=1; the determinant of matrix        A, as derived in Appendix A, is zero.

$\begin{matrix}\begin{matrix}\; & {A_{00{\_ h}} = {\min( {d,N} )}} & \; \\\; & {A_{01{\_ h}} = {\sum\limits_{i = {\max{({1,{d - N + 1}})}}}^{d}\; T_{i,h}}} & \; \\{{\forall h},} & {{A_{11{\_ h}} = {\sum\limits_{i = {\max{({1,{d - N + 1}})}}}^{d}\; T_{i,h}^{2}}},} & {d \geq 2} \\\; & {b_{0{\_ h}} = {\sum\limits_{i = {\max{({1,{d - N + 1}})}}}^{d}\; P_{i,h}}} & \; \\\; & {b_{1{\_ h}} = {\sum\limits_{i = {\max{({1,{d - N + 1}})}}}^{d}\;( {P_{i,h} \cdot T_{i,h}} )}} & \;\end{matrix} & (1)\end{matrix}$

-   -   Note that singularity will still occur for d>1 if T_(i,h) are        identical for a given h.    -   This example method uses at most N×24×2 data points, which are        stored for each day type.    -   At the implementer's discretion, equation 2 may be employed        instead of equation 1. Equation 2 modestly reduces computations.        However, equation 2 uses additional data that is stored (e.g.,        N×24×7 compared to N×24×2).

$\begin{matrix}\begin{matrix}\; & {A_{00{\_ h}} = {\min( {d,N} )}} \\\; & {A_{01{\_ h}} = \{ \begin{matrix}{{A_{01{\_ h}}^{*} + T_{d,h}},} & {{{if}\mspace{14mu} d} \leq N} \\{{A_{01{\_ h}}^{*} - T_{{d - N},h} + T_{d,h}},} & {otherwise}\end{matrix} } \\{{\forall h},} & {A_{11{\_ h}} = \{ \begin{matrix}{{A_{01{\_ h}}^{*} + T_{d,h}},} & {{{if}\mspace{14mu} d} \leq N} \\{{A_{11{\_ h}}^{*} - T_{{d - N},h}^{2} + T_{d,h}^{2}},} & {otherwise}\end{matrix} } \\\; & {b_{0{\_ h}} = \{ \begin{matrix}{{b_{0{\_ h}}^{*} + P_{d,h}},} & {{{if}\mspace{14mu} d} \leq N} \\{{b_{0{\_ h}}^{*} - P_{{d - N},h} + P_{d,h}},} & {otherwise}\end{matrix} } \\\; & {b_{1{\_ h}} = \{ \begin{matrix}{{b_{1{\_ h}}^{*} + {P_{d,h} \cdot T_{d,h}}},} & {{{if}\mspace{14mu} d} \leq N} \\{{b_{1{\_ h}}^{*} - P_{{d - N},h} + {P_{d,h} \cdot T_{d,h}}},} & {otherwise}\end{matrix} }\end{matrix} & (2)\end{matrix}$

-   -   -   A*₀₁, A*₁₁, b*₀, and b*₁ are A₀₁, A₁₁, b₀, and b₁ from the            preceding iteration, respectively.

    -   2. After matrix and vector elements have been calculated by        either equation 1 or equation 2, calculate the coefficients for        the linear model using equation 3.

$\begin{matrix}{{\forall h},\begin{matrix}{a_{0\_\; h} = \frac{{A_{11\_\; h}b_{0\_\; h}} - {A_{01\_\; h}b_{1\_\; h}}}{{A_{00\_\; h}A_{11\_\; h}} - A_{01\_\; h}^{2}}} \\{a_{1\_\; h} = \frac{{A_{00\_\; h}b_{1\_\; h}} - {A_{01\_\; h}b_{0\_\; h}}}{{A_{00\_\; h}A_{11\_\; h}} - A_{01\_\; h}^{2}}}\end{matrix}} & (3)\end{matrix}$

-   -   3. Generate {circumflex over (P)} for the upcoming four days        using the linear model in equation 4:        for D={d+1,d+2,d+3,d+4}, and ∀h,{circumflex over (P)} _(D,h) =a        _(0_h) +a _(1_h) ·T _(f_D,h)  (4)    -   The hourly standard deviation σ_(h), which is potentially a        useful indicator of the accuracy of and one's confidence in the        hourly prediction {circumflex over (P)}_(D,h), may be computed        as follows:

$\begin{matrix}{{\forall h},{\sigma_{h} = {\sqrt{\frac{1}{\min( {d,N} )}{\sum\limits_{i = {\max{({1,{d - N + 1}})}}}^{d}\;( {P_{i,h} - {\hat{P}}_{i,h}} )^{2}}} = \sqrt{\frac{1}{\min( {d,N} )}{\sum\limits_{i = {\max{({1,{d - N + 1}})}}}^{d}\;( {P_{i,h} - ( {a_{0\_\; h} + {a_{1\_\; h} \cdot T_{i,h}}} )} )^{2}}}}}} & (5)\end{matrix}$

-   -   4. Generate L_(inelastic_n) by allocating {circumflex over        (P)}_(D,h) to each n^(th) interval:

$\begin{matrix}{{\forall n},{L_{inelastic\_ n} = \{ \begin{matrix}\underset{\_}{{\hat{P}}_{D,h},} & {{{if}\mspace{14mu} n} \subseteq h} \\{{\hat{P}}_{D,h},} & {{{if}\mspace{14mu} n} \subseteq h}\end{matrix} }} & (6)\end{matrix}$

-   -   -   {circumflex over (P)}_(D,h) is the average of all            {circumflex over (P)}_(D,h) corresponding to all hours h            lying within n.        -   Make this L_(inelastic_n) prediction available as an output            of this function into the transactive node's algorithmic            toolkit framework.

    -   5. Each time a successive measurement pair becomes available,        repeat starting from step 1 above.

Subappendix A: Additional Details about the Formulation

This formulation is based on a first-order polynomial (linear) model ofpower {circumflex over (P)} as a function of temperature T, as shown inequation A1. This model's coefficients a₀, and a₁ are determined via aleast-squares error fit to pairs of measured power and temperature. Thecoefficients may be used thereafter to predict power given forecastedtemperatures.{circumflex over (P)}=a ₀ +a ₁ ·T  (A1)

The optimal coefficients are determined by minimization of the costfunction J shown in equation A2. This wisely chosen cost functionhappens to be the statistical variance of the difference between actualmeasured electrical load and load that is modeled by the linear modelduring N days of a given type (weekdays, or weekends/holidays). Thestandard deviation is the square root of the variance. The variance andstandard deviation are potentially useful indicators of the accuracy ofand one's confidence in the predictions that result from this function.

$\begin{matrix}{J = {\frac{1}{N}{\sum\limits_{i = 1}^{N}\;( {P_{i} - {\hat{P}}_{i}} )^{2}}}} & ( {A\; 2} )\end{matrix}$

The optimal coefficients are found by setting the partial derivatives ofthe cost function with respect to the two coefficients to zero, as shownin equation A3.

$\begin{matrix}{\begin{bmatrix}\frac{\partial J}{\partial a_{0}} \\\frac{\partial J}{\partial a_{1}}\end{bmatrix} = {\begin{bmatrix}{{- \frac{2}{N}}{\sum\limits_{i = 1}^{N}\;( {P_{i} - a_{0} - {a_{1} \cdot T_{i}}} )}} \\{{- \frac{2}{N}}{\sum\limits_{i = 1}^{N}\;( {{P_{i} \cdot T_{i}} - {a_{0} \cdot T_{i}} - {a_{1} \cdot T_{i}^{2}}} )}}\end{bmatrix} = 0}} & ( {A\; 3} )\end{matrix}$

Equation A3 can be written in matrix form, as in equation A4.

$\begin{matrix}{{\begin{bmatrix}N & {\sum\limits_{i = 1}^{N}\; T_{i}} \\{\sum\limits_{i = 1}^{N}\; T_{i}} & {\sum\limits_{i = 1}^{N}\; T_{i}^{2}}\end{bmatrix}\begin{bmatrix}a_{0} \\a_{1}\end{bmatrix}} = \begin{bmatrix}{\sum\limits_{i = 1}^{N}\; P_{i}} \\{\sum\limits_{i = 1}^{N}\;( {P_{i} \cdot T_{i}} )}\end{bmatrix}} & ( {A\; 4} )\end{matrix}$

The matrix is seen to be identical to its transpose. The simplifiedrepresentation given in equation A5 will prove useful in referring tothe various vector and matrix elements of equation A4.

$\begin{matrix}{{\begin{bmatrix}A_{00} & A_{01} \\A_{01} & A_{11}\end{bmatrix}\begin{bmatrix}a_{0} \\a_{1}\end{bmatrix}} = \begin{bmatrix}b_{0} \\b_{1}\end{bmatrix}} & ( {A\; 5} )\end{matrix}$

This is in the form Ax=b, the solution of which can be found by x=A⁻¹b,as long as matrix A is invertible or nonsingular. Formulas exist for theinversion of a 2×2 matrix, so each coefficient may be explicitly solvedfor as in equation A6. This explicit representation is advantageousbecause it alleviates any expectation that the computationalinfrastructure being relied upon to conduct this function necessarilypossesses any matrix solvers.

$\begin{matrix}\begin{matrix}{a_{0} = \frac{{A_{11}b_{0}} - {A_{01}b_{1}}}{{A_{00}A_{11}} - A_{01}^{2}}} \\{a_{1} = \frac{{A_{00}b_{1}} - {A_{01}b_{0}}}{{A_{00}A_{11}} - A_{01}^{2}}}\end{matrix} & ( {A\; 6} )\end{matrix}$

This method should not require a large set of training data, but somestartup issues may be encountered. There is no reasonable way to predictelectrical load before any comparable measurement has been made. Thecoefficients cannot be uniquely determined until at least twonon-identical temperature measurements have been taken for a given hourof the day.

Subappendix B: Example

In this example, real power (load) P and temperature T measurementsduring fourteen weekdays—given in Table 30 and Table 31,respectively—are used to compute {circumflex over (P)}, following theprocedure outlined in the Pseudo Code Implementation section. N=10. Theresulting {circumflex over (P)} is given in Table 32, and plotted alongwith ±1 standard deviation (e.g. ±√{square root over (J)}) and P in theset 4700 of graphs shown in FIG. 47. Notice that the “NaN” (not anumber) entries on day 3 are due to the singularity of matrix A causedby the identical temperature points at the corresponding hours on days 1and 2. FIG. 48 through FIG. 50 comprise sets 4800, 4900, 5000 of graphsthat show the linear least-squares error fit for each hour of the day,for days 4, 12, and 14, respectively, given the measured data.

TABLE 30 Power P Measurements in kW d 1 2 3 4 5 6 7 8 9 10 11 12 13 14 h0 126630 126380 123750 119310 108010  91850 101540  99580 110370 118090111810 108690  94420  99760 1 128540 127530 126080 119370 106720  90490101250  99270 110440 115540 112920 107110  92590  99970 2 130030 132390128840 118230 107120  90680 102500  99460 112350 115970 114350 106530 92940 101600 3 132300 134530 129970 119680 109430  92310 104400 100900116400 117040 118210 108160  93430 103750 4 136720 137780 131020 120650110730  93910 105960 102830 120110 117440 121380 108240  95000 106250 5141660 143280 135970 122840 113740  96180 110190 107220 126350 120040127690 112090  99450 111410 6 151840 151040 144810 131840 121820 105230119760 117030 135810 127720 135390 120230 108640 120590 7 164120 161680157710 142160 132860 114240 130250 129380 146520 138180 145470 129690116230 131540 8 166680 162390 158210 142940 134880 116610 131660 126770151070 140760 150230 130020 115310 131170 9 158610 156650 150760 137720132790 116310 126940 121170 146550 138550 145140 127470 112020 121080 10150280 145960 144010 131050 130430 107040 119110 113870 137590 135270135700 123850 107310 114660 11 140770 138850 138650 120960 124670 100140114120 107110 128370 128050 128430 120340 104290 108770 12 132130 130430134000 110740 120430  96160 111270 101900 120040 116560 122470 115930103010 105390 13 125840 125450 131130 105590 115060  96720 103900  97780113440 109900 115470 114020 103600 103400 14 120530 119940 130460 102400114400  93370 102900  94950 110830 106170 114590 114710 105380 101570 15118960 117000 129940 102900 111120  94600 101420  92960 109080 102160117490 116450 106720 102620 16 116740 116360 131310 103930 111810  94570102470  94420 109880 102600 118930 117110 110980 103650 17 123890 121190135200 107620 117810 102710 108120  99210 115810 108130 125210 119550114430 111170 18 137920 135820 141200 118540 125000 110720 119310 111320128410 120590 131300 126230 121330 118390 19 142510 139340 141880 122890123340 114190 121300 118170 132660 124750 133520 126760 121940 123540 20142980 138900 139110 122620 119860 114130 118760 119720 134420 126250128930 122130 116690 122810 21 142550 137650 135470 122060 117290 111990115170 117520 131880 124860 125790 116520 111650 120670 22 136270 133130130030 117390 112710 107870 109270 114110 128100 121910 120550 107950110480 114810 23 129740 126930 121660 112760 106290 103520 102800 111150121650 117880 111880  99490 100620 107230

TABLE 31 Temperature T Measurements in ° C. d 1 2 3 4 5 6 7 8 9 10 11 1213 14 h 0 −21.00 −22.00 −21.00 −14.00 −14.00 −4.00 −12.00 −10.00 −16.00−17.00 −22.00 −7.00 3.00 −3.00 1 −22.00 −22.00 −21.00 −14.00 −13.00−4.00 −11.00 −9.00 −17.00 −14.00 −21.00 −7.00 3.00 −4.00 2 −22.00 −23.00−21.00 −13.00 −13.00 −4.00 −12.00 −9.00 −17.00 −14.00 −21.00 −6.00 2.00−6.00 3 −23.00 −23.00 −19.00 −12.00 −12.00 −4.00 −13.00 −8.00 −23.00−12.00 −21.00 −7.00 3.00 −6.00 4 −22.00 −22.00 −20.00 −12.00 −10.00−5.00 −11.00 −8.00 −20.00 −11.00 −21.00 −6.00 2.00 −6.00 5 −23.00 −24.00−20.00 −12.00 −10.00 −5.00 −10.00 −8.00 −22.00 −11.00 −19.00 −6.00 3.00−7.00 6 −23.00 −24.00 −20.00 −12.00 −11.00 −8.00 −9.00 −8.00 −23.00−11.00 −19.00 −5.00 3.00 −7.00 7 −24.00 −23.00 −20.00 −11.00 −10.00−7.00 −8.00 −9.00 −22.00 −11.00 −19.00 −4.00 3.00 −7.00 8 −23.00 −22.00−18.00 −10.00 −9.00 −9.00 −8.00 −13.00 −22.00 −11.00 −21.00 −4.00 3.00−7.00 9 −19.00 −19.00 −16.00 −9.00 −9.00 −8.00 −8.00 −12.00 −20.00−10.00 −18.00 −3.00 3.00 −6.00 10 −17.00 −16.00 −14.00 −8.00 −8.00 −7.00−7.00 −9.00 −16.00 −8.00 −16.00 −2.00 4.00 −5.00 11 −16.00 −14.00 −13.00−4.00 −8.00 −5.00 −2.00 −9.00 −15.00 −8.00 −13.00 −2.00 1.00 −5.00 12−13.00 −13.00 −11.00 −4.00 −7.00 −3.00 −2.00 −6.00 −13.00 −8.00 −9.00−2.00 3.00 −5.00 13 −12.00 −11.00 −10.00 −4.00 −6.00 −2.00 −1.00 −6.00−12.00 −5.00 −7.00 −2.00 2.00 −4.00 14 −11.00 −8.00 −9.00 −4.00 −6.00−1.00 −2.00 −4.00 −11.00 −4.00 −5.00 −1.00 2.00 −4.00 15 −11.00 −7.00−9.00 −4.00 −5.00 −1.00 −2.00 −4.00 −10.00 −4.00 −6.00 −1.00 3.00 −4.0016 −12.00 −7.00 −9.00 −5.00 −4.00 1.00 −3.00 −5.00 −7.00 −5.00 −6.00−1.00 3.00 −3.00 17 −11.00 −8.00 −9.00 −3.00 −3.00 −1.00 −3.00 −6.00−9.00 −4.00 −6.00 0.00 3.00 −4.00 18 −16.00 −9.00 −9.00 −8.00 −4.00−2.00 −4.00 −7.00 −11.00 −13.00 −6.00 −1.00 3.00 −5.00 19 −18.00 −12.00−11.00 −8.00 −4.00 −2.00 −7.00 −13.00 −16.00 −11.00 −6.00 0.00 3.00−6.00 20 −19.00 −19.00 −12.00 −11.00 −5.00 −5.00 −6.00 −12.00 −16.00−19.00 −6.00 0.00 3.00 −6.00 21 −19.00 −19.00 −12.00 −12.00 −5.00 −5.00−6.00 −10.00 −16.00 −20.00 −7.00 1.00 0.00 −7.00 22 −21.00 −19.00 −15.00−13.00 −4.00 −11.00 −10.00 −12.00 −18.00 −18.00 −7.00 2.00 −3.00 −7.0023 −18.00 −19.00 −14.00 −15.00 −4.00 −11.00 −11.00 −17.00 −17.00 −20.00−6.00 2.00 −3.00 −7.00

TABLE 32 Predicted Load {circumflex over (P)} in kW d 1 2 3 4 5 6 7 8 910 11 12 13 14 h 0 — — 126630 116860 119280 97461 108369 103079 114703116243 126716 97364 87557 98185 1 — — NaN 112395 118233 95376 106179100882 117808 110548 125738 97212 84840 98109 2 — — 127670 114445 11814094987 109251 101292 119049 111531 127500 95262 86552 100584 3 — — NaN123941 120102 101061 114440 101943 134691 109605 126623 101920 90763102800 4 — — NaN 106100 116988 103511 112066 103657 132651 110065 132656101073 90988 104233 5 — — 136800 121254 119314 106297 112426 107226140265 113660 131096 104291 91067 109562 6 — — 154240 131262 130109119518 115470 114200 151411 121797 139185 110797 101535 118367 7 — —154360 143738 140592 130533 125652 129383 161018 133619 151356 119835111943 128784 8 — — 145230 145832 141494 138080 128147 141862 163310134415 157896 121255 114016 129418 9 — — NaN 134730 137518 133002 126763138324 159603 130209 150645 116328 112387 125733 10 — — 137320 131948131114 128706 120439 126313 147527 121093 145033 109665 106991 120504 11— — 137890 131747 128323 121719 105742 125792 137670 120420 131670109383 108827 115807 12 — — NaN 143520 119083 110190 100484 115130132834 117456 119772 103365 97644 111728 13 — — 125060 145988 112810102765 96465 113238 128199 107849 112711 101571 97728 107297 14 — —120137 126527 111990 97488 98285 106113 128043 104100 106987 97088 95781106263 15 — — 117980 119517 109447 99199 99613 106146 123478 103701108810 95299 92736 105769 16 — — 116512 122828 108659 101560 105818109718 112495 107500 109352 95750 92437 106631 17 — — 122090 126991109571 109435 111212 118081 122865 110506 114634 101191 102691 111875 18— — 135820 138594 125970 123013 120876 126128 131917 134944 121585117003 117667 121233 19 — — 138812 139867 123367 120126 126652 137312138238 129727 122264 118178 120110 123841 20 — — NaN 138849 120765120152 119458 129805 135371 140289 118805 114907 116592 121461 21 — —NaN 135470 117430 117330 116924 123902 134394 141283 117843 110225114585 118739 22 — — 126850 127799 102646 120991 116588 118679 128845128699 109237 101337 110449 113300 23 — — 140980 123450 94357 115177112747 121624 119604 124703 103275 98270 104107 106232

6.3.2 Bulk Inelastic Load—Recursive—Recursive Algorithm (Function 1.01a)

Description:

The following is the foundation of an alternative to the Bulk InelasticLoad toolkit functions 1.0 and 1.01. However, this functionalspecification can be implemented with measurements over only two priordays, expects less mathematical knowledge by implementers, is easilydocumented down to requisite steps, and for, these reasons, may be moreamenable to implementation by some utility implementers. Furthermore,unlike toolkit function 1.01 that uses a moving window of a chosennumber of days, this function 1.01a is formulated as a purely recursivealgorithm.

The basic approach is as follows: For a given circuit location, pairs ofelectrical load and ambient temperature are measured each hour. Datafrom the same hour-of-day and from a comparable day type are used torecursively update the coefficients of a linear model. This model isthen used to predict electrical load at this location for the samefuture day type and hour-of-day based on the forecasted ambienttemperature for the future hour.

Block Input/Output Function Model:

Inputs:

-   -   {P_(d,h), T_(d,h)}—[kW, ° C.]—paired measurements of actual        electrical power (load) and ambient temperature for a given day        d of a given type (weekday or weekend/holiday) and hour h of the        day at a circuit location. h=0, 1, . . . , 23. These        measurements taken each hour allow the recursive model to become        updated for the respective day type and hour-of-day.    -   N—[dimensionless]—number used in the recursive algorithm. The        selected value of N should be greater than 2. Default: 10 (e.g.,        about two weeks of weekdays or about a month of weekend/holiday        days).    -   T_(f_d,h)—[° C.]—forecasted temperature for a given future        hour-of-day h for a least the next four days (e.g., the        predicted time horizon of the transactive signals). This        forecasted temperature is the input to the model by which        electrical power load may be predicted for a given hour-of-day        and day type.

Interim Calculation Products:

-   -   a_(0_h), a_(1_h)—[kW, kW/° C.]—a set of coefficients that model        a best-fit prediction of electrical power from a forecasted        ambient temperature for a given hour-of-day on a given type of        day.    -   A_(01_h), A_(11_h), b_(0_h), b_(1_h)—set of four unique vector        and matrix elements that should be stored for each hour-of-day        for each day type. These elements are updated each time a new        pair of load and temperature measurements become available for        the respective hour-of-day and day type.    -   {circumflex over (P)}_(d,h)—[kW]—predicted load for each future        hour for the next four days. These are the outputs from the        linear model for the respective future hour-of-day and day type,        given the forecasted ambient temperature for that future hour.

Outputs:

-   -   L_(inelastic_n)—[kW]—predicted load corresponding to the n^(th)        interval. This is the hourly predicted load P_(d h) allocated        accordingly to each n^(th) interval.

Pseudo Code Implementation:

-   -   1. For the number m of available startup measurements, calculate        the initial A_(01_h), A_(11_h), b_(0_h), and b_(1_h). At        startup, two unique measurements (e.g., m=2) may be adequate.        More prior measurements are preferred and may be used. It should        be pointed out that singularity is unavoidable when m=1; the        determinant of matrix A, as derived in Appendix A, is zero.

$\begin{matrix}{{\forall h},\begin{matrix}{A_{01{\_ h}} = {\frac{1}{m}{\sum\limits_{i = 1}^{m}\; T_{i,h}}}} \\{A_{11{\_ h}} = {\frac{1}{m}{\sum\limits_{i = 1}^{m}\; T_{i,h}^{2}}}} \\{b_{0{\_ h}} = {\frac{1}{m}{\sum\limits_{i = 1}^{m}\; P_{i,h}}}} \\{b_{1{\_ h}} = {\frac{1}{m}{\sum\limits_{i = 1}^{m}\;( {P_{i,h} \cdot T_{i,h}} )}}}\end{matrix},{m \geq 2}} & (1)\end{matrix}$

-   -   2. Each time a successive measurement pair becomes available for        day d, A_(01_h), A_(11_h), b_(0_h), and b_(1_h) should be        recursively updated as in equation 2.

$\begin{matrix}{{\forall h},\begin{matrix}{A_{01{\_ h}} = \frac{{( {N - 1} ) \cdot A_{01\_\; h}^{*}} + T_{d,h}}{N}} \\{A_{11{\_ h}} = \frac{{( {N - 1} ) \cdot A_{11\_\; h}^{*}} + T_{d,h}^{2}}{N}} \\{b_{0{\_ h}} = \frac{{( {N - 1} ) \cdot b_{0\_\; h}^{*}} + P_{d,h}}{N}} \\{b_{1{\_ h}} = \frac{{( {N - 1} ) \cdot b_{1\_\; h}^{*}} + {P_{d,h} \cdot T_{d,h}}}{N}}\end{matrix}} & (2)\end{matrix}$

-   -   -   A*₀₁, A*₁₁, b*₀, and b*₁ are A₀₁, A₁₁, b₀, and b₁ from the            preceding iteration, respectively.

    -   3. Calculate the coefficients for the linear model using the        equation 3.

$\begin{matrix}{{\forall h},\begin{matrix}{a_{0{\_ h}} = \frac{{A_{11{\_ h}}b_{0{\_ h}}} - {A_{01{\_ h}}b_{1{\_ h}}}}{A_{11{\_ h}} - A_{01{\_ h}}^{2}}} \\{a_{1{\_ h}} = \frac{b_{1{\_ h}} - {A_{01{\_ h}}b_{0{\_ h}}}}{A_{11{\_ h}} - A_{01{\_ h}}^{2}}}\end{matrix}} & (3)\end{matrix}$

-   -   4. Generate {circumflex over (P)} for the upcoming four days        using the linear model in equation 4:        for D={d+1,d+2,d+3,d+4}, and ∀h,{circumflex over (P)} _(D,h) =a        _(0_h) +a _(1_h) ·T _(f_D,h)  (4)        -   If the d measurement pairs are stored and accessible, the            hourly standard deviation σ_(h), which is potentially a            useful indicator of the accuracy of and one's confidence in            the hourly prediction {circumflex over (P)}_(D,h), may be            computed as follows:

$\begin{matrix}{{\forall h},{\sigma_{h} = {\sqrt{\frac{1}{d}{\sum\limits_{i = 1}^{d}\;( {P_{i,h} - {\hat{P}}_{i,h}} )^{2}}} = \sqrt{\frac{1}{d}{\sum\limits_{i = 1}^{d}\;( {P_{i,h} - ( {a_{0\_\; h} + {a_{1\_\; h} \cdot T_{i,h}}} )} )^{2}}}}}} & (5)\end{matrix}$

-   -   5. Generate L_(inelastic_n) by allocating {circumflex over        (P)}_(D,h) to each n^(th) interval:

$\begin{matrix}{{\forall n},{L_{inelastic\_ n} = \{ \begin{matrix}{{\hat{P}}_{D,h},} & {{{if}\mspace{14mu} n} \subseteq h} \\\overset{\_}{{\hat{P}}_{D,h},} & {{{if}\mspace{14mu} h} \subseteq n}\end{matrix} }} & (6)\end{matrix}$

-   -   -   {circumflex over (P)}_(D,h) is the average of all            {circumflex over (P)}_(D,h) corresponding to all hours h            lying within n.        -   Make this L_(inelastic_n) prediction available as an output            of this function into the transactive node's algorithmic            toolkit framework.

    -   6. Repeat starting from step 2 above.

Subappendix A: Additional Details about the Formulation

This formulation is based on a first-order polynomial (linear) model ofpower {circumflex over (P)} as a function of temperature T, as shown inequation A1. This model's coefficients a₀, and a₁ are determined via aleast-squares error fit to pairs of measured power and temperature. Thecoefficients may be used thereafter to predict power given forecastedtemperatures.{circumflex over (P)}=a ₀ +a ₁ ·T  (A1)

The optimal coefficients are determined by minimization of the costfunction J shown in equation A2. This wisely chosen cost functionhappens to be the statistical variance of the difference between actualmeasured electrical load and load that is modeled by the linear modelduring N days of a given type (weekdays, or weekends/holidays). Thestandard deviation is the square root of the variance. The variance andstandard deviation are potentially useful indicators of the accuracy ofand one's confidence in the predictions that result from this function.

$\begin{matrix}{J = {\frac{1}{N}{\sum\limits_{i = 1}^{N}\;( {P_{i} - {\hat{P}}_{i}} )^{2}}}} & ({A2})\end{matrix}$

The optimal coefficients are found by setting the partial derivatives ofthe cost function with respect to the two coefficients to zero, as shownin equation A3.

$\begin{matrix}{\begin{bmatrix}\frac{\partial J}{\partial a_{0}} \\\frac{\partial J}{\partial a_{1}}\end{bmatrix} = {\begin{bmatrix}{{- \frac{2}{N}}{\sum\limits_{i = 1}^{N}\;( {P_{i} - a_{0} - {a_{1} \cdot T_{i}}} )}} \\{{- \frac{2}{N}}{\sum\limits_{i = 1}^{N}\;( {{P_{i} \cdot T_{i}} - {a_{0} \cdot T_{i}} - {a_{1} \cdot T_{i}^{2}}} )}}\end{bmatrix} = 0}} & ({A3})\end{matrix}$

Equation A3 can be written in matrix form, as in equation A4.

$\begin{matrix}{{\begin{bmatrix}1 & {\frac{1}{N}{\sum\limits_{i = 1}^{N}\; T_{i}}} \\{\frac{1}{N}{\sum\limits_{i = 1}^{N}\; T_{i}}} & {\frac{1}{N}{\sum\limits_{i = 1}^{N}\; T_{i}^{2}}}\end{bmatrix}\begin{bmatrix}a_{0} \\a_{1}\end{bmatrix}} = \begin{bmatrix}{\frac{1}{N}{\sum\limits_{i = 1}^{N}\; P_{i}}} \\{\frac{1}{N}{\sum\limits_{i = 1}^{N}\;( {P_{i} \cdot T_{i}} )}}\end{bmatrix}} & ({A4})\end{matrix}$

The matrix is seen to be identical to its transpose. The simplifiedrepresentation given in equation A5 will prove useful in referring tothe various vector and matrix elements of equation A4.

$\begin{matrix}{{\begin{bmatrix}1 & A_{01} \\A_{01} & A_{11}\end{bmatrix}\begin{bmatrix}a_{0} \\a_{1}\end{bmatrix}} = \begin{bmatrix}b_{0} \\b_{1}\end{bmatrix}} & ({A5})\end{matrix}$

This is in the form Ax=b, the solution of which can be found by x=A⁻¹b,as long as matrix A is invertible or nonsingular. Formulas exist for theinversion of a 2×2 matrix, so each coefficient may be explicitly solvedfor as in equation A6. This explicit representation is advantageousbecause it alleviates any expectation that the computationalinfrastructure being relied upon to conduct this function necessarilypossesses any matrix solvers.

$\begin{matrix}{{a_{0} = \frac{{A_{11}b_{0}} - {A_{01}b_{1}}}{A_{11} - A_{01}^{2}}}{a_{1} = \frac{b_{1} - {A_{01}b_{0}}}{A_{11} - A_{01}^{2}}}} & ({A6})\end{matrix}$

This method should not require a large set of training data, but somestartup issues may be encountered. There is no reasonable way to predictelectrical load before any comparable measurement has been made. If usednon-recursively according to the formulation so far, the coefficientscannot be uniquely determined until at least two non-identicalmeasurement pairs have been taken. Exceptions would be used to apply themethod until N>2.

After two non-identical measurements, the problem becomesover-determined, and the power of least-squares error fit comes intoplay. The question then becomes how many samples N to maintain and use.If a moving window is used, then one should store a cache of N datapairs. Furthermore, the cache should be maintained for all of the morethan 24×2 sets of hours and day types that are to be modeled. The movingwindow approach may not be especially efficient from a computational andstorage standpoint and should be avoided. A recursive approach ispreferred.

In a recursive formulation, one can keep a cache of only the four mostrecently calculated unique vector and matrix elements (A₀₁, A₁₁, b₁, andb₁) for each day type and its hours. Each of these elements is presumedto have already been influenced by at least N prior measurements. When anew measurement pair (P_(N+1), T_(N+1)) becomes available for this hourand hour type, one may recursively update elements as exemplified in A7for vector element b₁. The effect of this recursive formula is that theold vector element is replaced by a new term that is a weighted sum ofthe old element and a new term that uses the new measurements. If N islarge, the new measurements have less impact than they would if N weresmall.

$\begin{matrix}{b_{1} = \frac{{{( {N - 1} ) \cdot \frac{1}{N}}{\sum\limits_{i = 1}^{N}\;( {P_{i} \cdot T_{i}} )}} + {P_{N + 1} \cdot T_{N + 1}}}{N}} & ({A7})\end{matrix}$

Equation A8 more simply and generally shows how the old vector elementb*₁ becomes replaced by the new one b₁. The two weighting factors are(N−1)/N and 1/N, which sums to unity.

$\begin{matrix}{b_{1} = \frac{{( {N - 1} ) \cdot b_{1}^{*}} + {P_{N + 1} \cdot T_{N + 1}}}{N}} & ({A8})\end{matrix}$

Nothing prevents the application of recursive formulas of the typeexemplified by A7 and A8 after the elements have been initialized. Thefirst predictions may be wild and unreliable until more measurements canbecome incorporated into the model.

Subappendix B: Example

In this example, real power (load) P and temperature T measurementsduring fourteen weekdays—given in Table 33 and Table 34,respectively—are used to compute {circumflex over (P)}, following theprocedure outlined in the Pseudo Code Implementation section. Theresulting {circumflex over (P)} is given in Table 35, and plotted alongwith ±1 standard deviation (e.g. ±√{square root over (J)}) and Pin theset 5100 of graphs in FIG. 51. Notice that the “NaN” (not a number)entries on day 3 are due to the singularity of matrix A caused by theidentical temperature points at the corresponding hours on days 1 and 2.FIG. 52 through FIG. 54 are sets 5200, 5300, 5400 of graphs that showthe linear least-squares error fit for each hour of the day, for days 4,12, and 14, respectively, given the measured data.

TABLE 33 Power P Measurements in kW D 1 2 3 4 5 6 7 8 9 10 11 12 13 14 h0 126630 126380 123750 119310 108010 91850 101540 99580 110370 118090111810 108690 94420 99760 1 128540 127530 126080 119370 106720 90490101250 99270 110440 115540 112920 107110 92590 99970 2 130030 132390128840 118230 107120 90680 102500 99460 112350 115970 114350 10653092940 101600 3 132300 134530 129970 119680 109430 92310 104400 100900116400 117040 118210 108160 93430 103750 4 136720 137780 131020 120650110730 93910 105960 102830 120110 117440 121380 108240 95000 106250 5141660 143280 135970 122840 113740 96180 110190 107220 126350 120040127690 112090 99450 111410 6 151840 151040 144810 131840 121820 105230119760 117030 135810 127720 135390 120230 108640 120590 7 164120 161680157710 142160 132860 114240 130250 129380 146520 138180 145470 129690116230 131540 8 166680 162390 158210 142940 134880 116610 131660 126770151070 140760 150230 130020 115310 131170 9 158610 156650 150760 137720132790 116310 126940 121170 146550 138550 145140 127470 112020 121080 10150280 145960 144010 131050 130430 107040 119110 113870 137590 135270135700 123850 107310 114660 11 140770 138850 138650 120960 124670 100140114120 107110 128370 128050 128430 120340 104290 108770 12 132130 130430134000 110740 120430 96160 111270 101900 120040 116560 122470 115930103010 105390 13 125840 125450 131130 105590 115060 96720 103900 97780113440 109900 115470 114020 103600 103400 14 120530 119940 130460 102400114400 93370 102900 94950 110830 106170 114590 114710 105380 101570 15118960 117000 129940 102900 111120 94600 101420 92960 109080 102160117490 116450 106720 102620 16 116740 116360 131310 103930 111810 94570102470 94420 109880 102600 118930 117110 110980 103650 17 123890 121190135200 107620 117810 102710 108120 99210 115810 108130 125210 119550114430 111170 18 137920 135820 141200 118540 125000 110720 119310 111320128410 120590 131300 126230 121330 118390 19 142510 139340 141880 122890123340 114190 121300 118170 132660 124750 133520 126760 121940 123540 20142980 138900 139110 122620 119860 114130 118760 119720 134420 126250128930 122130 116690 122810 21 142550 137650 135470 122060 117290 111990115170 117520 131880 124860 125790 116520 111650 120670 22 136270 133130130030 117390 112710 107870 109270 114110 128100 121910 120550 107950110480 114810 23 129740 126930 121660 112760 106290 103520 102800 111150121650 117880 111880 99490 100620 107230

TABLE 34 Temperature T Measurements in ° C. d 1 2 3 4 5 6 7 8 9 10 11 1213 14 h 0 −21.00 −22.00 −21.00 −14.00 −14.00 −4.00 −12.00 −10.00 −16.00−17.00 −22.00 −7.00 3.00 −3.00 1 −22.00 −22.00 −21.00 −14.00 −13.00−4.00 −11.00 −9.00 −17.00 −14.00 −21.00 −7.00 3.00 −4.00 2 −22.00 −23.00−21.00 −13.00 −13.00 −4.00 −12.00 −9.00 −17.00 −14.00 −21.00 −6.00 2.00−6.00 3 −23.00 −23.00 −19.00 −12.00 −12.00 −4.00 −13.00 −8.00 −23.00−12.00 −21.00 −7.00 3.00 −6.00 4 −22.00 −22.00 −20.00 −12.00 −10.00−5.00 −11.00 −8.00 −20.00 −11.00 −21.00 −6.00 2.00 −6.00 5 −23.00 −24.00−20.00 −12.00 −10.00 −5.00 −10.00 −8.00 −22.00 −11.00 −19.00 −6.00 3.00−7.00 6 −23.00 −24.00 −20.00 −12.00 −11.00 −8.00 −9.00 −8.00 −23.00−11.00 −19.00 −5.00 3.00 −7.00 7 −24.00 −23.00 −20.00 −11.00 −10.00−7.00 −8.00 −9.00 −22.00 −11.00 −19.00 −4.00 3.00 −7.00 8 −23.00 −22.00−18.00 −10.00 −9.00 −9.00 −8.00 −13.00 −22.00 −11.00 −21.00 −4.00 3.00−7.00 9 −19.00 −19.00 −16.00 −9.00 −9.00 −8.00 −8.00 −12.00 −20.00−10.00 −18.00 −3.00 3.00 −6.00 10 −17.00 −16.00 −14.00 −8.00 −8.00 −7.00−7.00 −9.00 −16.00 −8.00 −16.00 −2.00 4.00 −5.00 11 −16.00 −14.00 −13.00−4.00 −8.00 −5.00 −2.00 −9.00 −15.00 −8.00 −13.00 −2.00 1.00 −5.00 12−13.00 −13.00 −11.00 −4.00 −7.00 −3.00 −2.00 −6.00 −13.00 −8.00 −9.00−2.00 3.00 −5.00 13 −12.00 −11.00 −10.00 −4.00 −6.00 −2.00 −1.00 −6.00−12.00 −5.00 −7.00 −2.00 2.00 −4.00 14 −11.00 −8.00 −9.00 −4.00 −6.00−1.00 −2.00 −4.00 −11.00 −4.00 −5.00 −1.00 2.00 −4.00 15 −11.00 −7.00−9.00 −4.00 −5.00 −1.00 −2.00 −4.00 −10.00 −4.00 −6.00 −1.00 3.00 −4.0016 −12.00 −7.00 −9.00 −5.00 −4.00 1.00 −3.00 −5.00 −7.00 −5.00 −6.00−1.00 3.00 −3.00 17 −11.00 −8.00 −9.00 −3.00 −3.00 −1.00 −3.00 −6.00−9.00 −4.00 −6.00 0.00 3.00 −4.00 18 −16.00 −9.00 −9.00 −8.00 −4.00−2.00 −4.00 −7.00 −11.00 −13.00 −6.00 −1.00 3.00 −5.00 19 −18.00 −12.00−11.00 −8.00 −4.00 −2.00 −7.00 −13.00 −16.00 −11.00 −6.00 0.00 3.00−6.00 20 −19.00 −19.00 −12.00 −11.00 −5.00 −5.00 −6.00 −12.00 −16.00−19.00 −6.00 0.00 3.00 −6.00 21 −19.00 −19.00 −12.00 −12.00 −5.00 −5.00−6.00 −10.00 −16.00 −20.00 −7.00 1.00 0.00 −7.00 22 −21.00 −19.00 −15.00−13.00 −4.00 −11.00 −10.00 −12.00 −18.00 −18.00 −7.00 2.00 −3.00 −7.0023 −18.00 −19.00 −14.00 −15.00 −4.00 −11.00 −11.00 −17.00 −17.00 −20.00−6.00 2.00 −3.00 −7.00

TABLE 35 Predicted Load {circumflex over (P)} in kW d 1 2 3 4 5 6 7 8 910 11 12 13 14 h 0 — — 126630 124191 119498 96626 108269 102805 114650116329 127101 96474 85579 98352 1 — — NaN 112395 118196 94929 105910100573 117443 110287 125689 96505 83045 98352 2 — — 127670 112362 11798494487 108956 100904 118733 111250 127527 94263 84303 101254 3 — — NaN123941 120116 101062 113747 101384 133700 109346 127434 101173 86802103607 4 — — NaN 106100 116809 103093 111749 103192 132447 109778 133525100222 87433 104971 5 — — 136800 121561 119302 106235 112052 106958139419 113423 131534 103789 88863 110968 6 — — 154240 134747 130419119543 115100 114163 150572 121766 139918 109873 98412 119912 7 — —154360 142393 140515 130391 125117 129120 159899 133373 151689 118670109277 130146 8 — — 145230 143146 141225 137822 127300 141211 163014133587 158918 118595 109151 130867 9 — — NaN 134730 137507 132860 126121137835 160160 129541 152236 113491 107649 127317 10 — — 137320 127838130750 128511 119661 125622 146717 120059 145536 107769 103493 122319 11— — 137890 130499 128391 121910 105218 125576 138497 120412 132764107940 107169 117351 12 — — NaN 143520 118649 110789 100537 114747131530 117284 119690 102612 97249 114317 13 — — 125060 137416 112662104182 97282 112642 126957 107679 112801 101343 97428 110096 14 — —120137 121422 113458 103761 100347 106438 124786 104472 107208 9892998885 109909 15 — — 117980 116726 111867 105021 102011 106541 120376104146 108635 97775 97505 109736 16 — — 116512 118213 112656 108185106796 109286 111196 107311 108670 100318 100467 109828 17 — — 122090119859 111253 111212 111197 116548 121170 110107 114007 102980 105753115742 18 — — 135820 136638 129992 126212 123068 126902 131885 134883122509 117508 116577 125388 19 — — 138812 138298 127833 122911 127317136713 139585 130864 122535 117216 118237 127802 20 — — NaN 138849120367 120023 119184 129288 135266 140450 118000 113418 114014 124063 21— — NaN 135470 116724 117127 116668 123607 134221 141567 117392 107961113130 121303 22 — — 126850 126981 103428 121141 116431 118619 129812129610 107833 98446 109999 115050 23 — — 140980 124582 95629 115900113221 123598 122204 128027 101939 95493 103983 108230

6.3.3 Transactive Imported Energy (Function 1.2)

Description:

Converts transactive signals from transactive neighbors into frameworkparameter outputs that are expected by the toolkit framework.

Application: A transactive node typically should restate the transactivesignals that it receives in terms of toolkit framework parameters.

This toolkit function is so basic that it may be treated as part of thetoolkit framework.

Block Input/Output Function Model:

Inputs:

Current IST time series.

Transactive incentive signals (TIS) from each transactive neighbor.

Transactive feedback signals (TFS) from each transactive neighbor.

Outputs:

TIS restated as energy terms C_(E).

TFS restated as energy terms P_(G) for the intervals during which theTFS represents imported energy.

6.3.4 Small Wind Generator Negative Load (Function 1.4)

Description:

This function is to predict the power to be produced by small windenergy resources. This function is preferred where a relatively smallamount of wind renewable generation offsets load at a location.

If the energy from a wind energy resource should directly affect thetransactive incentive signal (TIS) at this location and electricallydownstream locations, the energy from this resource should beincorporated with the Wind Energy resource and incentive toolkitfunction instead.

This function applies to locations that host relatively small windgenerators or wind sites that primarily offset a larger electrical load.

Block Input/Output Function Model:

Inputs:

-   -   {u_(k)}—[m/s]—Time series of predicted wind speed for a future        interval k, for the upcoming four days (time horizon of        transactive signals), based on wind speed data recorded at a        height h, at or close to the location under consideration.        Although granular data is desired, this function is formulated        to work with any available data interval.    -   h—[m]—Height at which wind speed is predicted.    -   ψ—[unitless]—Wind turbine manufacturer and model information to        be chosen from this preliminary text enumeration:        -   Honeywell WT6500        -   Windspire 1.2        -   Home Energy Americas V200        -   Skystream        -   Bergey Excel 10        -   Urban Green Energy UGE-4K        -   Tangarie Gale 10        -   WePower Falcon 5.5        -   Wing-Power Prototype    -   This enumeration should be augmented whenever a new wind turbine        is to be considered.    -   m—[count]—Number of wind turbines.    -   h_(hub)—[m]—wind turbines' representative hub height.    -   K_(n)—[unitless]—Time series availability fraction, e.g.        fraction of turbines or wind site that is predicted to be online        during each n^(th) IST interval, where n=0, 1, . . . , 55. Wind        generation may be limited or entirely unavailable due to        maintenance schedules and other reasons.

Interim Calculation Products:

-   -   {U_(hub,k)}—[m/s]—Time series of predicted wind speed for a        future interval k at the wind turbines' representative hub        height h_(hub).

Output:

-   -   {L_(n)}—[kW]—Time series of average power to be produced by wind        turbine(s) for each future n^(th) IST interval.

Pseudo Code Implementation:

-   -   1. Restate inputs in the units specified in previous section, if        necessary.    -   2. Compute {u_(hub,k)}:        -   Based on the wind profile power law relationship (Elliot            1986):

$\begin{matrix}{{\forall k},{u_{{hub},k} = {( \frac{h_{hub}}{h} )^{\alpha} \cdot u_{k}}}} & (1)\end{matrix}$

-   -   -   -   α—[unitless]—An empirically derived constant for the                location of the wind turbine(s). If empirical derivation                is not possible, 1/7 may be used as an approximation.

        -   The implementer may choose to use a different            approach/relationship, if deemed more appropriate/accurate.

    -   3. Generate {L_(n)}:        -   For the given ψ input, generate {L_(k)} by looking up, from            Table 36, an L_(k) corresponding to each u_(hub,k):

TABLE 36 Lookup table for wind turbine power output at a given windspeed L [kW] ome Energy Bergey Urban Green WePower Wing- u HoneywellWindspire Americas Skystream Excel Energy UGE- Tangarie Falcon Power[m/s] WT6500 1.2 V200 3.7 10 4K Gale 10 5.5 Prototype 1.0 0.009 0 0 00.020 0 0 0 0 1.5 0.015 0 0 0 0.030 0 0 0 0 2.0 0.025 0 0 0 0.080 00.333 0 0 2.5 0.038 0 0 0 0.105 0.041 0.617 0 0 3.0 0.048 0 0.005 00.159 0.082 0.833 0.066 0.029 3.5 0.074 0 0.014 0.024 0.254 0.123 1.1670.166 0.072 4.0 0.103 0.030 0.025 0.072 0.382 0.185 1.417 0.298 0.1304.5 0.128 0.065 0.040 0.144 0.636 0.247 1.667 0.464 0.202 5.0 0.1710.115 0.059 0.220 0.891 0.309 2.167 0.633 0.276 5.5 0.209 0.160 0.0820.336 1.209 0.391 2.667 0.895 0.391 6.0 0.251 0.220 0.100 0.456 1.5270.514 3.083 1.127 0.492 6.5 0.285 0.283 0.122 0.600 2.036 0.658 3.5831.358 0.593 7.0 0.333 0.350 0.145 0.744 2.482 0.823 4.167 1.590 0.6947.5 0.392 0.425 0.178 0.936 2.991 0.988 4.833 1.855 0.809 8.0 0.4570.525 0.225 1.104 3.627 1.193 5.500 2.087 0.911 8.5 0.500 0.610 0.2851.320 4.391 1.440 6.167 2.319 1.012 9.0 0.583 0.750 0.372 1.542 5.2181.708 6.833 2.584 1.128 9.5 0.651 0.880 0.460 1.780 6.109 2.058 7.6672.916 1.272 10.0 0.714 1.025 0.552 2.000 6.936 2.366 8.417 3.346 1.46010.5 0.793 1.138 0.642 2.136 7.891 2.675 9.250 3.877 1.692 11.0 0.8881.188 0.733 2.254 8.909 3.086 10.000 4.340 1.894 11.5 0.981 1.200 0.8222.325 10.055 3.601 11.000 4.771 2.082 12.0 1.069 1.200 0.900 2.37210.945 4.012 12.000 5.102 2.226 12.5 1.172 1.175 1.005 2.396 11.7094.074 13.083 5.300 2.313 13.0 1.250 1.138 1.100 2.410 12.091 4.00014.167 5.400 2.356 13.5 1.357 1.000 1.214 2.410 12.345 4.000 15.1675.500 2.400 14.0 1.466 0.300 1.325 2.396 12.473 4.000 16.417 5.500 2.400

The information in Table 36 is plotted in graph 5500 of FIG. 55. Table36 is based on information available in the datasheets or brochures ofthese wind turbines. The powers given for 32 m/s are to be used forspeeds beyond 32 m/s. The datasheet of this wind turbine claims that itdoes not have a cut-out wind speed. Therefore, the power output has beenextrapolated beyond 20 m/s. However, the extrapolated data should bereplaced if more accurate data is available. This wind turbine has acut-out speed of 30 m/s, but power output data between 20 and 30 m/s ismissing in its datasheet. This data has been extrapolated here, butshould be replaced if more accurate data is available. No cut-out speedinformation is given in the datasheet of this wind turbine. It isassumed that there is no cut-out speed and the power output has beenextrapolated beyond 14 m/s. This data has been extrapolated here, butshould be replaced if more accurate data is available. There is nodatasheet for this prototype wind turbine. Given its similarities withthe WePower Falcon 5.5, its power versus wind speed data is assumed tobe a scaled version of the Falcon 5.5. However, this data should bereplaced by either empirical data or such data from a different source.

-   -   Allocate {L_(k)} to each n^(th) interval, scale by m, and        multiply by K to generate {L_(n)}:

$\begin{matrix}{{\forall n},{L_{n} = \{ \begin{matrix}{{m \cdot K_{n} \cdot L_{k}},} & {{{if}\mspace{14mu} n}\; \subseteq k} \\{{m \cdot K_{n} \cdot \overset{\_}{L_{k}}},} & {{{if}\mspace{14mu} k} \subseteq n}\end{matrix} }} & (2)\end{matrix}$

-   -   -   L_(k) —[kW]—weighted-average of all L_(k) within n.

    -   Make this {L_(n)} prediction available as an output of this        function into the transactive node's algorithmic toolkit        framework.

6.3.5 Small-Scale Solar Generator Negative Load (Function 1.6)

Description:

This function is to predict the power to be produced by small solarenergy resources. This function is preferred where a relatively smallamount of solar renewable generation offsets load at a location.

If the energy from a solar energy resource should directly affect thetransactive incentive signal (TIS) at this location and electricallydownstream locations, the energy from this resource should beincorporated with the Solar Energy resource and incentive toolkitfunction instead.

This function applies to locations that host relatively small solargenerators or solar sites that primarily offset a larger electricalload.

Block Input/Output Function Model:

Inputs:

-   -   {GTI_(k)}—[kW/m²]—Time series of predicted Global Tilted        Irradiance (GTI) for a future interval k, for the upcoming four        days (time horizon of transactive signals), based on solar        irradiance data recorded at or close to the location under        consideration. (GTI=DNI·cos(θ_(i))+DIF·(1−β/180°), where DNI is        the Direct Normal Irradiance, DIF the Diffuse Horizontal        Irradiance, A the inclination angle of the tilted plate, and        θ_(i) the angle between DNI and the normal of the tilted plate.        DNI and DIF are the actual data measured at the location under        consideration. Furthermore, cos(θ_(i))=cos β·cos Z+sin β·sin        Z·cos(θ−ψ), where θ and Z are the sun's azimuth and zenith,        respectively. Note that there are known equations to compute θ        and Z throughout the day, every day, at a given latitude.)        Although granular data is desired, this function is formulated        to work with any available data interval. The GTI represents the        effective irradiance normal to a tilted surface. For a fixed        flat-plate photovoltaic (PV) collector, the computation of GTI        is, therefore, dependent on its inclination angle β and azimuth        ψ, as defined below. Note also that GTI may not be shared        amongst solar generators unless they have the same inclination        and azimuth. For a solar-tracking collector or concentrating        collector, the computation of GTI should assume that the normal        of the solar collector is in line with the Direct Normal        Irradiance (DNI).    -   β—[°]—Inclination angle of the fixed flat-plate PV collector.        This is 0° for systems laying horizontal to the ground. This is        not required for solar-tracking collectors, including        concentrating collectors.    -   ψ—[°]—Azimuth of the fixed flat-plate PV collector. This is 180°        for systems facing due south. This is not required for        solar-tracking collectors, including concentrating collectors.    -   A—[m²]—Effective surface area of the solar collector.    -   η—[%]—Overall conversion efficiency of the solar energy        resource, e.g. from the incident solar power (e.g., GTI·A) to        the usable alternating current (AC) power. This should be the        product of the efficiencies of the solar collector and its power        converter, and, if possible, should include conduction losses.        The implementer may choose to model this overall efficiency as a        function of power. While the efficiency of the solar collector        may be constant at different power levels, the efficiency of the        power converter varies. The efficiency versus power curve of the        converter is sometimes published in its datasheet. Conduction        losses also vary with power, but may be harder to quantify and        model.    -   m—[count]—Number of such solar energy resources that is being        modeled by this function.    -   K_(n)—[unitless]—Time series availability fraction, e.g.        fraction of solar energy resources or solar site that is        predicted to be online during each n^(th) IST interval, where        n=0, 1, . . . , 55. Solar generation may be limited or entirely        unavailable due to maintenance schedules and other reasons.

Interim Calculation Product:

-   -   {L_(k)}—[kW]—Time series of average power to be produced by one        solar energy resource for each future interval k.

Output:

-   -   {L_(n)}—[kW]—Time series of average power to be produced by the        solar energy resource(s) for each future n^(th) interval.

Pseudo Code Implementation:

-   -   1. Restate inputs in the units specified in previous section, if        necessary.    -   2. Generate {L_(k)}:        -   For each future interval k, compute the average power            {L_(k)} to be produced by one solar energy resource:            ∀k,L _(k)=GTI_(k) ·A·η  (2)    -   3. Generate {L_(n)}:        -   Allocate {L_(k)} to each n^(th) interval, scale by m, and            multiply by K_(n) to generate {L_(n)}:

$\begin{matrix}{{\forall n},{L_{n} = \{ \begin{matrix}{{m \cdot K_{n} \cdot L_{k}},} & {{{if}\mspace{14mu} n}\; \subseteq k} \\{{m \cdot K_{n} \cdot \overset{\_}{L_{k}}},} & {{{if}\mspace{14mu} k} \subseteq n}\end{matrix} }} & (3)\end{matrix}$

-   -   -   -   L_(k) —[kW]—weighted-average of all L_(k) within n.

    -   Make this {L_(n)} prediction available as an output of this        function into the transactive node's algorithmic toolkit        framework.

6.3.6 General Event-Driven Demand (Function 2.0)

Description:

This is a very general function for predicting the behaviors ofresponsive load assets that only infrequently respond to events that maybe identified from an incentive signal. When these assets respond, theytransition to a limited number of available response levels. Thisgeneral function may serve as a template for functions that are morenarrowly targeted to specific responsive asset systems. This functionhas been written at such a high level that it will not likely bereferenced and used for any asset system. But this function descriptionwill be valuable guidance to those who design more specific functionsfor more specific asset systems.

This function can respond to absolute or relative TIS as desired by anapplication.

This function applies to many responsive asset systems that conducttraditional demand response several times a month. Response mayadditionally define a “critical” response level for extreme conditions.

Block Input/Output Function Model:

Inputs:

Current IST time series.

TIS time series. Recent history (e.g., 1 day to 1 week) of TIS that maybe used if relative TIS is to be tracked in a statistical sense.

Numbers of assets in this asset system population that may be used toscale this function.

Typical daily or weekly inelastic load profile for the asset systemsthat are being predicted by this function. This profile is a startingpoint for predicting the inelastic load component.

Outputs:

Predicted inelastic load at for each IST interval.

Predicted change in elastic load for each IST interval.

Predicted advisory control signal for this asset system.

Pseudo Code Implementation:

Inelastic load component.

This algorithm will not predict an inelastic load component. Inelasticload components are better addressed by inelastic load functions thathave been defined.

Elastic Load Component.

This algorithm will calculate (1) predicted change in electrical load inresponse to the incentive signal (e.g., the asset's elasticity), (2)“events” during which an asset is predicted to respond, and (3) thepredicted advisory control signal that will be sent to this elasticasset system.

Predicted Change in Electrical Load in Response to the Incentive Signal.

To predict a change in energy that can result from this asset systemduring events, this function should model the consumption (orgeneration) of energy by this asset system. At least two approaches canbe accommodated: (1) An explicit time-series load shape may be used torepresent the responsive load (or generation) from this asset system.Alternatively, (2) A dynamic model of this asset system may be simulatedto predict the effect that an event will have on the asset system. Theseapproaches will be compared by discussing how each one could be used topredict the change in electrical load that could be had from a set ofresidential tank water heaters.

Explicit Time-Series Load Shape.

The average electrical load consumed during each hour of a day by aresidential 40-gallon tank electric water heater may be obtained. Insome cases, regional and seasonal variations may be found. See(Hammerstrom 2007, FIG. 4.18) for example. The load curves represent theaverage power that is expected to be consumed by an electric waterheater at any time of the day. In many cases, splines will allow suchload curves to be very efficiently stored and reproduced. The number ofwater heaters in the asset system population is a scaling factor thatmay be used to predict the entire consumption by this population ofwater heaters. If an event were to occur and cause this population ofwater heaters to become curtailed, the change in energy consumption bythese water heaters would be predicted well by knowing the number ofwater heaters, the representative load curve for a single water heater,and the time and duration of the event.

Dynamic Asset System Model.

The same population of electric water heaters may be more rigorouslymodeled using a physics-based model of a water heater. In this case, onecould input typical residential hot water consumption instead of anelectrical load curve. As water is consumed, hot water leaves the watertank, cold water enters the water tank, and the temperature of the waterin the tank decreases. The modeled thermostat turns on the electricalheating element and heats the water at a rate that is determined by thepower rating of a heating element. If the model being used is accurate,the resulting electrical load curve would also be accurate on a“typical” day.

However, if a curtailment is predicted, the response of the dynamicwater heater model can predict secondary effects that could not havebeen modeled otherwise. After a period of electrical curtailment, thewater in the tank will have become relatively cold. When the curtailmentperiod ends, additional energy is then used to reheat the cool, storedwater to the desired temperature. A rebound effect is thereby predictedat the conclusion of the curtailment event.

Events During which this Asset is Predicted to Respond.

The capabilities and availability of the modeled asset system determinea set of incentive thresholds that should be managed by this function. Athreshold may be a function of time. An asset system that has only twomodes of operation (e.g., normal and curtailed) will define only onethreshold. Generally, an asset system that has m modes of operationshould define m−1 thresholds. The resulting thresholds, in turn, definem−1 levels of response for an asset system. (The “Normal” mode ofoperation is indeed a mode of operation, but it is usually notconsidered a response level.) “Events” occur any time that the predictedincentive signal exceeds a defined threshold to invoke one of the levelsof response that is a feature of this asset system.

The availability of asset systems that are responsive either on anevent-based or time-of-use basis may be predicted if limitations on thenumbers and durations of events are stated. For example, a utility mighthave contracted with its customers that a responsive asset will notbecome curtailed by the utility more often than four times per calendarmonth and that none of these curtailments will not endure for more than2 hours.

Over time, statistical distributions and correlations emerge from thedynamic behaviors of the incentive signal. This function may incorporatethe behaviors of past historical incentive signals and the predictedincentive signals as these statistics are being compiled. This functionmay thereafter refer to such statistics to evaluate and predict where athreshold should be placed to initiate just fewer than the allowednumber of events and just less than the allowed duration of events.Automated event-driven demand response will be attempting to identifyevents within monthlong durations, so these functions should use theactual incentive signal (not its statistical average), or it shouldtrack the statistical average of the incentive signal quite slowly incomparison with that duration.

Predicted Advisory Control Signal.

Once events have been predicted, the predicted advisory control signalmay be stated, aligned in time with the predicted events, according tothe standardized method described in the appendix entitled “StandardAdvisory Output Control Signal”. In the referenced method, thecapabilities of this asset system and, in some cases, the severity of anevent determine which integer member of a signed byte signal will besent to the asset system. (The domain of relevant advisory controlsignals will be relatively small for functions that are formulated forspecific asset systems.)

6.3.7 Incentive Function—Wind Energy (Function 2.1)

Description:

This function addresses wind power generation and is to be applied attransactive nodes which have and represent wind farm energy that isproduced within or near their electrical boundaries to encourage the useof wind energy when and near where it is generated. This function isapplicable to energy produced by a wind farm or may be applied toaggregated output from multiple wind farms.

The cost of supplying the wind energy generated is applied as aninfrastructure cost, in units of cost per time, consistent with theTransactive Node Framework. For simplicity, the infrastructure cost willuse the $2155/kW capacity-weighted average installed cost for a windfarm. The infrastructure cost of a wind farm can thus be estimated ifits capacity is known. This cost shall then be spread over the lifetimeT of the wind farm.

Note that this calculation typically yields an infrastructure cost near$0.010/kW/h ($10/MW/h) if a 25-year lifetime is assumed. It ispermissible for the implementer of this function to assume thatT=2.19×10⁵ hours (25 years) if better estimates are unavailable for thelifetime of the wind farm installation.

After a wind farm exceeds its planned lifetime, a decision should bemade. Thereafter, the infrastructure cost may be (a) zeroed out, (b)replaced by ongoing maintenance costs, or (c) continued as before as anongoing replacement cost. This function should be revisited and refinedwhen this situation will be encountered.

This function should also predict the electrical power that will beproduced by the wind resource during each future interval. An explicitalgorithm could be created to convert predicted weather conditions (likewind speed and direction) into electrical power output. This functionwill assume that experts satisfy this goal by predicting electricalpower output from meteorological data that is available to them.

Block Input/Output Function Model:

Inputs:

P—Wind farm capacity/power rating.

T—Lifetime of wind farm.

IST_(n)—Present time series interval start times used by an exampletoolkit framework, where n=0, 1, . . . , 56. (There is no prediction tocorrespond with IST_(n) for n=56. This last IST is simply used to makeit clear when the final interval concludes.)

Meteorological data—Predicted wind speed, wind direction, relativehumidity and perhaps other weather data that experts may use to predictelectrical power production for wind farms.

Outputs:

C_(I,n)—Time series of infrastructure cost terms expected by theTransactive Node Framework (unit: $/h); series members correspond toIST_(n). Infrastructure costs are not expected to be dynamic, but it isspecified as a time series for consistency with the Transactive NodeFramework.

P_(G,n)—Time series of predicted electrical power generated by wind farm(unit: average kW); series members correspond to IST_(n).

C_(E,n)—Time series of energy cost terms (unit: cost per energy). Sincethe cost of supplying the wind energy generated is applied purely as aninfrastructure cost, these energy cost terms should simply be set tozero. Note that these terms go in pair with the P_(G,n) terms and areused by the Transactive Node Framework.

Pseudo Code Implementation:

-   -   1. If necessary, restate P in kW and T in h (hour).    -   2. Compute the infrastructure cost C_(I,n) corresponding to        IST_(n) for n, as in equation (1).

$\begin{matrix}{{C_{I,n} = \frac{( {{\$ 2155}\text{/}{kW}} ) \times P}{T}},{{{for}\mspace{14mu} n} = 0},1,\ldots\mspace{14mu},55} & (1)\end{matrix}$

-   -   3. Predict the average wind electrical power output P_(G,n) that        will be generated during each future interval corresponding to        IST_(n) for n.    -   4. Output C_(E,n)=0, for n=0, 1, . . . , 55.

6.3.8 Incentive Function—Solar Energy (Function 2.2)

Description:

This function addresses solar power generation and is to be applied attransactive nodes which have and represent solar farm energy that isproduced within or near their electrical boundaries to encourage the useof solar energy when and near where it is generated. This function isapplicable to energy produced by a solar farm or may be applied toaggregated output from multiple solar farms.

The cost of supplying the solar energy generated is applied as aninfrastructure cost, in units of cost per time, consistent with theTransactive Node Framework. For simplicity, the infrastructure cost willuse the $7.5/W capacity-weighted average installed cost for a solarfarm. The infrastructure cost of a solar farm can thus be estimated ifits capacity is known. This cost shall then be spread over the lifetimeT of the solar farm.

Note that this calculation typically yields an infrastructure cost near$0.034/kW/h ($34/MW/h) if a 25-year lifetime is assumed. It ispermissible for the implementer of this function to assume thatT=2.19×10⁵ hours (25 years) if better estimates are unavailable for thelifetime of the solar farm installation.

After a solar farm exceeds its planned lifetime, a decision should bemade. Thereafter, the infrastructure cost may be (a) zeroed out, (b)replaced by ongoing maintenance costs, or (c) continued as before as anongoing replacement cost. This function should be revisited and refinedwhen this situation will be encountered.

This function should also predict the electrical power that will beproduced by the solar resource during each future interval. An explicitalgorithm could be created to convert predicted weather conditions (likesolar irradiance and temperature) into electrical power output. Thisfunction will assume that experts satisfy this goal by predictingelectrical power output from meteorological data that is available tothem.

Block Input/Output Function Model:

Inputs:

P—Solar farm capacity/power rating.

T—Lifetime of solar farm.

IST_(n)—Present time series interval start times used by the toolkitframework, where n=0, 1, . . . , 56. (There is no prediction tocorrespond with IST_(n) for n=56. This last IST is simply used to makeit clear when the final interval concludes.)

Meteorological data—Solar irradiance, temperature, and perhaps otherweather data that experts may use to predict electrical power productionfor solar farms.

Outputs:

C_(I,n)—Time series of infrastructure cost terms expected by theTransactive Node Framework (unit: $/h); series members correspond toIST_(n). Infrastructure costs are not expected to be dynamic, but it isspecified as a time series for consistency with the Transactive NodeFramework.

P_(G,n)—Time series of predicted electrical power generated by solarsite (unit: average kW); series members correspond to IST_(n).

C_(E,n)—Time series of energy cost terms (unit: cost per energy). Sincethe cost of supplying the solar energy generated is applied purely as aninfrastructure cost, these energy cost terms should simply be set tozero. Note that these terms go in pair with the P_(G,n) terms and areused by the Transactive Node Framework.

Pseudo Code Implementation:

-   -   1. If necessary, restate P in W and T in h (hour).    -   2. Compute the infrastructure cost C_(I,n) (units: $/h)        corresponding to IST_(n) for n, as in equation (1).

$\begin{matrix}{{C_{I,n} = \frac{( {{\$ 7}{.5}\text{/}W} ) \times P}{T}},{{{for}\mspace{14mu} n} = 0},1,\ldots\mspace{14mu},55} & (1)\end{matrix}$

-   -   3. Predict the average solar electrical power output P_(G,n)        that will be generated during each future interval corresponding        to IST_(n) for n.    -   4. Output C_(E,n)=0, for n=0, 1, . . . , 55.

6.3.9 Incentive Function—Hydropower (Function 2.3)

Description:

This function is to predict the amount and cost of hydroelectric energywhen and near where it is generated. It should at least representfederal hydropower of the region, but should strive to represent allregional hydropower. This function applies to transactive nodes that ownor represent hydropower generation within their electrical boundaries.At least transmission zones 4, 5, 6, 7, 8, 10, 11, 12, and 14 are withinthe Columbia River Basin and would be expected to host federalhydropower. Based on the predicted generated powers of non-hydro sourcesat a transactive node and their associated costs of energy, andhistorical electricity market prices, this function predicts theweighted-average cost of energy of hydropower generation.

Block Input/Output Function Model:

Inputs:

-   -   {P_(s,t)}, t=t₀, t₀+1 hour, . . . , t₀+i, . . . , t₀+I, . . .        —[kW]—Aggregated hourly scheduled hydropower generation (both        must-run and flexible), at the transactive node at which this        function is being implemented, for each hour of at least the        next four days (e.g., the predicted time horizon of the        transactive signals). Where this input cannot be known, trends        may be used.    -   {C_(m,h,d)}, h=00:00, 01:00, . . . , 23:00; d=−1, −2, . . . ,        −7—[$/kWh]—Historical electricity market price trading for every        hour starting at h of the day d, for the past 7 days. (A trend        based on the electricity market price for the past 7 days is        more likely to represent the expected market price for the next        four days.) The Dow Jones Mid-Columbia Electricity Price Indexes        is an example of a source for such information.    -   {K_(h,s)}, h=00:00, 01:00, . . . , 23:00, s=four seasons of the        year—[unitless]—fraction/percentage of total scheduled        hydropower generation, representing an estimate for flexible        hydropower generation during every hour starting at h of a given        season s.    -   C_(mustrun)—[$/kWh]—cost of energy for must-run hydropower        generation. This cost may have to be updated yearly, seasonally,        or at some shorter interval. (This cost of energy for must-run        hydropower generation is an estimate obtained from a        hypothetical supply stack provided by BPA and included in        Subappendix A.)

Interim Calculation Products:

-   -   {C_(trend,h)}, h=00:00, 01:00, . . . , 23:00—[$/kWh]—Trended        electricity market price by hour starting at h of the day.    -   {C_(flexible,n)}, n=0, 1, . . . , 55—[$/kWh]—cost of energy for        flexible hydropower generation, corresponding to the n^(th)        interval.

Outputs:

-   -   {P_(G,n)}—[kW]—Total hydropower generation, corresponding to the        n^(th) interval    -   {C_(E,n)}—[$/kWh]—Weighted-average cost of energy for        hydropower, corresponding to the n^(th) interval.

Pseudo Code Implementation:

-   -   1. Restate inputs in the units specified in previous section, if        necessary.    -   2. Generate P_(G,n):        -   Allocate of the scheduled hydropower generation to each            n^(th) interval.

$\begin{matrix}{{\forall n},{P_{G,n} = \{ \begin{matrix}{P_{s,{t_{0} + i}},} & {{{if}\mspace{14mu} n}\mspace{11mu} \subseteq \begin{matrix}\lbrack {( {t_{0} + i + 1} ) -}  \\ ( {t_{0} + i} ) \rbrack\end{matrix}} \\{{\frac{1}{( {t_{0} + I} ) - ( {t_{0} + i} )}{\sum\limits_{t = {t_{0} + i}}^{t_{0} + I - 1}\; P_{s,t}}},} & {{{if}\mspace{14mu}\lbrack {( {t_{0} + I} ) - ( {t_{0} + i} )} \rbrack} \subseteq n}\end{matrix} }} & (1)\end{matrix}$

-   -   -   Make this P_(G,n) prediction available as an output of this            function into the transactive node's algorithmic toolkit            framework.

    -   3. Calculate or update the trend for hour-by-hour electricity        market price that may be used to predict C_(flexible) if better        predictions are not known. For each hour starting at h of the        day, calculate the average electricity market price for the past        7 days. If an implementer possesses better means to make these        predictions, then such predictions should replace this trend        information as it becomes available.

$\begin{matrix}{{\forall h},{C_{{trend},h} = {\frac{1}{7}{\sum\limits_{d = {- 7}}^{- 1}\; C_{m,h,d}}}}} & (2)\end{matrix}$

-   -   -   Successive daily updates may be accomplished as follows:            ∀h,C _(trend,h)= 1/7(7·C _(trendh,h,old) −C _(m,h,−8) +C            _(m,h,−1))  (3)        -   C_(trend,h,old)—[$/kWh]—Prior value of C_(trend,h) that will            become displaced by this update.

    -   4. C_(flexible) usually hovers around the electricity market        price. Therefore, it can be predicted by allocating the        electricity market price trend to each n^(th) interval:

$\begin{matrix}{{\forall n},{C_{{flexible},n} = \{ \begin{matrix}\underset{\_}{C_{{trend},h_{i}},} & {{{if}\mspace{14mu} n}\mspace{11mu} \subseteq ( {h_{i + 1} - h_{i}} )} \\{C_{{trend},h},} & {{{if}\mspace{14mu}\lbrack {( {t_{0} + I} ) - ( {t_{0} + i} )} \rbrack} \subseteq n}\end{matrix} }} & (4)\end{matrix}$

-   -   -   C_(trend,h) —[$/kWh]—Average of all C_(trend,h) between t₀+i            and t₀+I (exclusive).

    -   5. Generate C_(E,n):        -   Allocate K_(h,s) to each n^(th) interval. Table 37 below is            a lookup table from which K_(h,s) is picked for a given hour            h in a season s.

$\begin{matrix}{{\forall n},{K_{n} = \{ \begin{matrix}\underset{\_}{K_{h_{i},s},} & {{{if}\mspace{14mu} n}\mspace{11mu} \subseteq ( {h_{i + 1} - h_{i}} )} \\{K_{h,s},} & {{{if}\mspace{14mu}\lbrack {( {t_{0} + I} ) - ( {t_{0} + i} )} \rbrack} \subseteq n}\end{matrix} }} & (5)\end{matrix}$

-   -   -   K_(h,s) —[unitless]—Average of all K_(h,s) between t₀+i and            t₀+I (exclusive).

TABLE 37 Lookup table for K_(h, s) S Mar. 21 to Jun. 21 to Sep. 21 toDec. 21 to Jun. 20 Sep. 20 Dec. 20 Mar. 20 h (Spring) (Summer) (Fall)(Winter) 00:00 10% 10% 10% 10% 01:00  0%  0%  0%  0% 02:00  0%  0%  0% 0% 03:00  0%  0%  0%  0% 04:00  0%  0%  0%  0% 05:00  5% 10% 20%  5%06:00 10% 20% 20%  5% 07:00 15% 20% 30%  5% 08:00 15% 25% 30% 10% 09:0015% 25% 40% 15% 10:00 15% 25% 40% 20% 11:00 15% 25% 40% 25% 12:00 15%25% 40% 30% 13:00 15% 25% 40% 35% 14:00 15% 20% 40% 35% 15:00 15% 10%40% 35% 16:00 15%  5% 40% 30% 17:00 15%  5% 40% 20% 18:00 15%  5% 40%20% 19:00 15% 10% 40% 20% 20:00 15% 15% 30% 20% 21:00 15% 20% 20% 20%22:00 10% 20% 20% 10% 23:00  5% 10% 10% 10%

-   -   -   Flexible hydropower is traded hourly on the electricity            market by BPA and non-BPA stakeholders. The cost of flexible            hydropower varies not only hourly, but also seasonally and            during short-term events like a heat wave during winter. The            cost of flexible hydropower usually hovers around the            current electricity market price. Further, the values for            K_(h,s) given in the above table are based on the expert            opinion of BPA's hydropower subject matter expert, and not            actual historical hydropower data.        -   Compute C_(E,n) as follows:            ∀n,C _(E,n)=(1−K _(n))·C _(mustrun) +K _(n) ·C            _(flexible,n)  (6)        -   Make this C_(E,n) prediction available as an output of this            function into the transactive node's algorithmic toolkit            framework.

Subappendix A: Hypothetical Supply Stack

FIG. 56 is a graph 5600 of a hypothetical supply stack.

Subappendix B: Derivation of C_(E,n)

$\begin{matrix}{{TIS}_{n} = \frac{\begin{matrix}{{{C_{{mustrun},n} \cdot P_{{mustrun},n} \cdot \Delta}\; t_{n}} +} \\{{{C_{{flexible},n} \cdot P_{{flexible},n} \cdot \Delta}\; t_{n}} + {{all}\mspace{14mu}{other}\mspace{14mu}{costs}}}\end{matrix}}{{{P_{{mustrun},n} \cdot \Delta}\; t_{n}} + {{P_{{flexible},n} \cdot \Delta}\; t_{n}} + {{all}\mspace{14mu}{other}\mspace{14mu}{energies}}}} & ( {B{.1}} ) \\{ \Rightarrow{TIS}_{n}  = \frac{\begin{matrix}{{{C_{{mustrun},n} \cdot ( {1 - K_{n}} ) \cdot P_{G,n} \cdot \Delta}\; t_{n}} +} \\{{{C_{{flexible},n} \cdot K_{n} \cdot P_{G,n} \cdot \Delta}\; t_{n}} + {{all}\mspace{14mu}{other}\mspace{14mu}{costs}}}\end{matrix}}{{{( {1 - K_{n}} ) \cdot P_{G,n} \cdot \Delta}\; t_{n}} + {{K_{n} \cdot P_{G,n} \cdot \Delta}\; t_{n}} + {{all}\mspace{14mu}{other}\mspace{14mu}{energies}}}} & ( {B{.2}} ) \\{\mspace{79mu}{ \Rightarrow{TIS}_{n}  = \frac{\begin{matrix}{( {{( {1 - K_{n}} ) \cdot C_{{mustrun},n}} + {K_{n} \cdot C_{{flexible},n}}} ) \cdot} \\{{{P_{G,n} \cdot \Delta}\; t_{n}} + {{all}\mspace{14mu}{other}\mspace{14mu}{costs}}}\end{matrix}}{{{P_{G,n} \cdot \Delta}\; t_{n}} + {{all}\mspace{14mu}{other}\mspace{14mu}{energies}}}}} & ( {B{.3}} ) \\{\mspace{79mu}{ \Rightarrow{TIS}_{n}  = \frac{{{C_{E,n} \cdot P_{G,n} \cdot \Delta}\; t_{n}} + {{all}\mspace{14mu}{other}\mspace{14mu}{costs}}}{{{P_{G,n} \cdot \Delta}\; t_{n}} + {{all}\mspace{14mu}{other}\mspace{14mu}{energies}}}}} & ( {B{.4}} ) \\{\mspace{79mu}{{\therefore C_{E,n}} = {{( {1 - K_{n}} ) \cdot C_{{mustrun},n}} + {K_{n} \cdot C_{{flexible},n}}}}} & ( {B{.5}} )\end{matrix}$

Subappendix C: Examples of C_(E,n)

-   -   Let C_(mustrun)=$0.0035/kWh as shown in Appendix A.    -   In these examples, the sample shown in diagram 5700 of FIG. 57,        which shows Dow Jones Mid-C Hourly Index is used for        C_(trend,h):        -   Note that, although not explicitly written in FIG. C1, the            price is in terms of $/MWh.

TABLE 38 Trended electricity market price by the hour h C_(trend, h)[$/kWh]  0:00 0.02083  1:00 0.02330  2:00 0.02231  3:00 0.02272  4:000.02773  5:00 0.03443  6:00 0.03356  7:00 0.03489  8:00 0.03493  9:000.03583 10:00 0.03276 11:00 0.03276 12:00 0.02859 13:00 0.02859 14:000.03010 15:00 0.02507 16:00 0.02228 17:00 0.02762 18:00 0.02898 19:000.03047 20:00 0.02603 21:00 0.02071 22:00 0.02945 23:00 0.02097

-   -   -   Allocate the C_(trend,h) values in Table 38 to each n^(th)            interval to obtain C_(flexible,n), and the K_(h,s) values to            obtain K_(n) for each season. Then compute C_(E,n) for each            season using equation (6). The outcome is given below in            Table 39 and plotted in FIG. 58.

TABLE 39 Examples of the overall cost of energy for hydropower for eachseason Δt_(n) C_(flexible,n) K_(n) C_(E,n) [$/kWh] n [h] [$/kWh] SpringSummer Fall Winter Spring Summer Fall Winter 0 1/12 0.0208 10% 10% 10%10% 0.0052 0.0052 0.0052 0.0052 1 1/12 0.0208 10% 10% 10% 10% 0.00520.0052 0.0052 0.0052 2 1/12 0.0208 10% 10% 10% 10% 0.0052 0.0052 0.00520.0052 3 1/12 0.0208 10% 10% 10% 10% 0.0052 0.0052 0.0052 0.0052 4 1/120.0208 10% 10% 10% 10% 0.0052 0.0052 0.0052 0.0052 5 1/12 0.0208 10% 10%10% 10% 0.0052 0.0052 0.0052 0.0052 6 1/12 0.0208 10% 10% 10% 10% 0.00520.0052 0.0052 0.0052 7 1/12 0.0208 10% 10% 10% 10% 0.0052 0.0052 0.00520.0052 8 1/12 0.0208 10% 10% 10% 10% 0.0052 0.0052 0.0052 0.0052 9 1/120.0208 10% 10% 10% 10% 0.0052 0.0052 0.0052 0.0052 10 1/12 0.0208 10%10% 10% 10% 0.0052 0.0052 0.0052 0.0052 11 1/12 0.0208 10% 10% 10% 10%0.0052 0.0052 0.0052 0.0052 12 ¼ 0.0233  0%  0%  0%  0% 0.0035 0.00350.0035 0.0035 13 ¼ 0.0233  0%  0%  0%  0% 0.0035 0.0035 0.0035 0.0035 14¼ 0.0233  0%  0%  0%  0% 0.0035 0.0035 0.0035 0.0035 15 ¼ 0.0233  0%  0% 0%  0% 0.0035 0.0035 0.0035 0.0035 16 ¼ 0.0223  0%  0%  0%  0% 0.00350.0035 0.0035 0.0035 17 ¼ 0.0223  0%  0%  0%  0% 0.0035 0.0035 0.00350.0035 18 ¼ 0.0223  0%  0%  0%  0% 0.0035 0.0035 0.0035 0.0035 19 ¼0.0223  0%  0%  0%  0% 0.0035 0.0035 0.0035 0.0035 20 ¼ 0.0227  0%  0% 0%  0% 0.0035 0.0035 0.0035 0.0035 21 ¼ 0.0227  0%  0%  0%  0% 0.00350.0035 0.0035 0.0035 22 ¼ 0.0227  0%  0%  0%  0% 0.0035 0.0035 0.00350.0035 23 ¼ 0.0227  0%  0%  0%  0% 0.0035 0.0035 0.0035 0.0035 24 ¼0.0277  0%  0%  0%  0% 0.0035 0.0035 0.0035 0.0035 25 ¼ 0.0277  0%  0% 0%  0% 0.0035 0.0035 0.0035 0.0035 26 ¼ 0.0277  0%  0%  0%  0% 0.00350.0035 0.0035 0.0035 27 ¼ 0.0277  0%  0%  0%  0% 0.0035 0.0035 0.00350.0035 28 ¼ 0.0344  5% 10% 20%  5% 0.0050 0.0066 0.0097 0.0050 29 ¼0.0344  5% 10% 20%  5% 0.0050 0.0066 0.0097 0.0050 30 ¼ 0.0344  5% 10%20%  5% 0.0050 0.0066 0.0097 0.0050 31 ¼ 0.0344  5% 10% 20%  5% 0.00500.0066 0.0097 0.0050 32 1 0.0336 10% 20% 20%  5% 0.0065 0.0095 0.00950.0050 33 1 0.0349 15% 20% 30%  5% 0.0082 0.0098 0.0129 0.0051 34 10.0349 15% 25% 30% 10% 0.0082 0.0114 0.0129 0.0066 35 1 0.0358 15% 25%40% 15% 0.0083 0.0116 0.0164 0.0083 36 1 0.0328 15% 25% 40% 20% 0.00790.0108 0.0152 0.0094 37 1 0.0328 15% 25% 40% 25% 0.0079 0.0108 0.01520.0108 38 1 0.0286 15% 25% 40% 30% 0.0073 0.0098 0.0135 0.0110 39 10.0286 15% 25% 40% 35% 0.0073 0.0098 0.0135 0.0123 40 1 0.0301 15% 20%40% 35% 0.0075 0.0088 0.0141 0.0128 41 1 0.0251 15% 10% 40% 35% 0.00670.0057 0.0121 0.0110 42 1 0.0223 15% 5% 40% 30% 0.0063 0.0044 0.01100.0091 43 1 0.0276 15% 5% 40% 20% 0.0071 0.0047 0.0131 0.0083 44 10.0290 15% 5% 40% 20% 0.0073 0.0048 0.0137 0.0086 45 1 0.0305 15% 10%40% 20% 0.0075 0.0062 0.0143 0.0089 46 1 0.0260 15% 15% 30% 20% 0.00690.0069 0.0103 0.0080 47 1 0.0207 15% 20% 20% 20% 0.0061 0.0069 0.00690.0069 48 1 0.0295 10% 20% 20% 10% 0.0061 0.0087 0.0087 0.0061 49 10.0210  5% 10% 10% 10% 0.0044 0.0052 0.0052 0.0052 50 6 0.0252  3%  3% 5%  3% 0.0040 0.0042 0.0046 0.0040 51 6 0.0341 14% 23% 33% 13% 0.00780.0106 0.0137 0.0076 52 6 0.0270 15% 15% 40% 31% 0.0070 0.0070 0.01290.0108 53 6 0.0261 13% 13% 27% 17% 0.0063 0.0065 0.0095 0.0073 54 240.0281 11% 14% 26% 16% 0.0062 0.0069 0.0100 0.0074 55 24 0.0281 11% 14%26% 16% 0.0062 0.0069 0.0100 0.0074

FIG. 58 is a plot 5800 of exemplary overall cost of energy forhydropower for each season.

6.3.10 Load Function—Residential Event-Driven Demand Response (Function2.4)

Description:

This toolkit function addresses systems of residential demand-responseequipment that will be expected to respond relatively infrequently(e.g., perhaps several times per month) to events that will be indicatedvia the transactive control and coordination system's incentive signal(TIS).

This toolkit function addresses systems that control any combination of(1) residential space heating, (2) residential electric tank waterheaters, or (3) smart appliances. Two or more different types ofequipment from this list may be grouped into a single asset system andmay consequently be described by a single instantiation of this toolkitfunction. This function allows for multiple response levels. A singleasset system uses one single set of thresholds and response levels. Ifdifferent sets of thresholds (e.g., different demand-response events)should be defined for different types or populations of equipment, thenadditional functions should be instantiated for each such type orpopulation.

Refer to toolkit load function 2.0 General Event-Driven Demand Responsefor general guidance and principles that were used during theformulation of this function. The section Pseudo Code Implementationbelow (and the detailed pseudo code in Subappendix F) lays out thespecific calculation strategy and steps of this function.

Block Input/Output Function Model

Inputs:

-   -   K_(L)—[dimensionless count]—number of response levels to be        prescribed for this asset system. For example, an asset system        that simply curtails its loads has one response level (e.g.,        “curtailed”).    -   D_(min,L)—[time: minutes]—minimum time duration for which an        event level L should remain in force after it has become        initiated. This duration is also the width of a time window that        will be used for evaluating the magnitude of an event at        level L. Note that if a D_(min,L) is specified, it is        recommended that some D_(x,L) limitation (see two bullets below)        is also specified. This is dictated by equation 8 in the Pseudo        Code Implementation section. If no D_(x) limitation is        specified, there is the risk of an event lasting for undesirable        lengths of time.    -   {N_(this year, L), N_(year, L), N_(this month, L), N_(month, L),        N_(this week, L), N_(week, L), N_(this day, L), N_(day, L),        N_(this hour, L), N_(hour, L)}—[dimensionless count]—local        static input LI_29—limitations on event count or        frequency—constraints that have been placed on the maximum        number of events that may occur for this system of assets during        a given time interval. For example, the set of inputs        {N_(this year, L)=36, N_(this month, L)=6, N_(month, L)=6,        N_(this day, L)=1} specifies that this asset system is permitted        to conduct no more than 36 events over a calendar year, not more        than six being conducted during any calendar month or past        30-day-long period, and not more often than once over a given        calendar day (e.g., period from midnight until midnight) for a        given response level L. Note that if any limitation N_(x,L) is        specified, the corresponding D_(x,L) limitation (see next        bullet) should also be specified. (This is dictated by equation        8 in the Pseudo Code Implementation section. If no D_(x)        limitation is specified, there is the risk of an event lasting        for undesirable lengths of time.)    -   {D_(this year, L), D_(year, L), D_(this month, L), D_(month, L),        D_(this week, L), D_(week, L), D_(this day, L), D_(day, L),        D_(this hour, L), D_(hour, L), D_(this event, L)}—[time        duration: minutes]—local static input LI_30—limitations on        curtailment event duration—constraints that have been placed on        the maximum total duration of events that may endure during a        given time interval.    -   {TIS₀(t), TIS₀(t−5), . . . , TIS₀(t−5k)}—[$/kWh]—recent history        of transactive incentive signals (TIS) by which the statistical        likelihood of various incentive levels will be assessed and        updated. The TIS₀ values from the TIS time series (e.g., the TIS        values that correspond to IST₀) from the last k five-minute        updates are used.    -   {TIS₀, TIS₁, . . . , TIS_(K-1)}—[$/kWh]—current transactive        incentive signal TIS for K future intervals.    -   P_(wh)(t)—[average kW]—typical electrical power consumption by        residential tank water heaters in this region as a function of        time of day. This function may be available as a function or as        a look-up table. See appendix material for an example.    -   OPTIONAL INPUT: {Level, EventStartTime_(L),        EventDuration_(L)}—[Integer, UTC Time, UTC Duration]—records of        events and their durations for events that actually have        occurred at each level L. If this input is unavailable, the        function should infer that events will have occurred every time        that an event response is advised by this function. If this        input is explicitly provided, then the toolkit function can more        accurately know how many events and their durations remain to be        applied into the future.

Interim Calculation Products:

-   -   {DIST_(L)(TIS_(0,min)), DIST_(L)(TIS_(0,min)+Δ$), . . . ,        DIST_(L)(TIS_(0,max)−Δ$)}—[dimensionless]—distributions of        absolute TIS₀ values based on historic TIS incentive signals and        filtered by simple windows of width D_(min, L).    -   {N′_(this year, L), N′_(year, L), N′_(this month, L),        N′_(month, L), N′_(this week, L), N′_(week, L),        N′_(this day, L), N′_(day, L), N′_(this hour, L),        N′_(hour, L)}—[dimensionless count]—cumulative count of actual        events L that have occurred during each of the intervals for        which limitations have been prescribed. Events L may be called        only when the numbers of actual events are fewer than the        numbers of allowed events for relevant intervals in LI_29. (This        set need not be an an explicit input. The function        implementation accepts the responsibility to know how many        events have occurred of each type and how many remain to use in        the future.)    -   {D′_(this year, L), D′_(year, L), D′_(this month, L),        D′_(month, L), D′_(this week, L), D′_(week, L),        D′_(this day, L), D′_(day, L), D′_(this hour, L), D′_(hour, L),        D′_(this event, L)}—[time duration: minutes]—actual cumulative        duration of events of level L at a given point in time. An event        L may be called provided that the event will not cause any total        allowed event duration to exceed the limits established by input        LI_30. (This set need not be an explicit input. The function        implementation accepts the responsibility to know the        accumulated durations of events of each type have occurred and        how much event time remains to use in the future.)

Outputs:

-   -   {ACS₀, ACS₁, . . . , ACS_(K-1)}—[dimensionless]—advisory control        signal for each K future predicted interval. A standardized        approach has been specified by which planned response levels may        be indicated by integer values [−127,127].    -   {ΔL₀, ΔL₁, . . . , ΔL_(K-1)}—[kW]—average change in power caused        by the elastic behavior of this asset system for the K future        predicted intervals. The elements of this series will be        non-negative during each future interval for which a response        event has been planned, corresponding to non-zero elements of        the asset control plan.

Pseudo Code Implementation:

-   -   1. Establish/update the statistical distribution sof historical        TIS values. (This process does not require or infer that the        distribution of TIS incentive signals is normal.)        -   a. For each unique D_(min, L), tally the number of times            that the average TIS₀ over interval D_(min, L) falls within            each of a set of bins b, where Δ$ is the size of the bin and            is fixed at $0.001/kWh.            TIS_(0,k,mean)=mean(TIS₀(IST_(0,k) −D            _(min,L)<IST₀≤IST_(0,k)))            IF TIS_(0,b)≤TIS_(0,k,mean)<TIS_(0,b)+Δ$,THEN            DIST_(L)(TIS_(0,b))=DIST_(L)(TIS_(0,b))+1  (1)            -   TIS_(0,b)—[$/kWh]—lower boundary of distribution                interval DIST_(L)(TIS_(0,b)), bin b            -   TIS_(0,b)+Δ$—[$/kWh]—upper boundary of distribution                interval DIST_(L)(TIS_(0,b)), bin b            -   DIST_(L)(TIS_(0,b))—[dimensionless]—a tally count of the                number of times that the average value of TIS₀ falls                into the interval bin b over time. (Because the                distribution will be normalized, it is equally valid to                sum the durations of the intervals, resulting in a tally                count of minutes.)        -   b. Using the distribution for each unique D_(min, L), create            a normalized cumulative distribution ϕ_(L)(TIS₀) as shown in            equation 2. The interpretation of ϕ_(L)(TIS₀) is the            fraction of filtered TIS₀ that will be expected to fall in            any of the bins below bin b, inclusive. By subtracting            ϕ_(L)(TIS_(0,b)) from 1.0, one estimates the fraction of            filtered TIS₀ values that would be greater than            TIS_(0,b)+Δ$.

$\begin{matrix}{{\Phi_{L}( {TIS}_{0,b} )} = \frac{\sum\limits_{i = {TIS}_{0,\min}}^{{TIS}_{0,b}}\;{{DIST}_{L}(i)}}{\sum\limits_{i = {TIS}_{0,\min}}^{{TIS}_{0,\max} - {\Delta}}\;{{DIST}_{L}(i)}}} & (2)\end{matrix}$

-   -   -   -   ϕ_(L)(TIS₀)—[dimensionless]—normalized cumulative                distribution of historical averaged TIS₀ values at level                L.            -   TIS_(0,min)=−$3/kWh and TIS_(0,max)=+$3/kWh

TABLE 40 Useful distribution organization for tracking the distributionof averaged TIS₀ values DIST(TIS₀) ϕ(TIS_(0, b)) TIS_(0, max) − Δ$ . . .TIS_(0, b) . . . TIS_(0, min) + Δ$ TIS_(0, min)

A skilled implementer may choose to fit the normalized cumulativedistribution ϕ(TIS₀) column of Table 40 to a monotonic function thatcould be used hereafter instead of this lookup table. FIG. 59 showsexample graphs 5900 for DIST(TIS₀) and ϕ(TIS₀).

-   -   c. For each unique D_(min, L), DIST_(L)(TIS_(0,b)) and        ϕ_(L)(TIS_(0,b)) may be updated whenever a new series of TIS        becomes available. (One may choose to update DIST(TIS_(0,b)) and        ϕ(TIS_(0,b)) at a time interval of his choice.)    -   2. Update incentive thresholds for this system of assets. The        overall process by which allowed numbers and durations of event        levels will establish thresholds against which future TIS₀        values may be compared is as follows:        -   The TIS threshold at which response level L should be            initiated is the TIS value at which no more than the allowed            event counts N_(L) or allowed total event durations D_(L)            will transpire.        -   This condition is satisfied by the minimum value of            TIS_(0,b) that satisfies all the conditions represented by            equations 3 through 6.    -   For a calendar interval (e.g., those that state “this interval,”        meaning that they are relevant to a given calendar year, month,        week, day, hour), the normalized cumulative distribution        ϕ_(L)(TIS₀) should meet all conditions for any defined interval        of equations 3 and 4.

$\begin{matrix}{{\Phi_{L}( {TIS}_{0} )} > {1 - \frac{D_{{{this}\mspace{11mu} x},L}( {1 - {N_{{{this}\mspace{11mu} x},L}^{\prime}/N_{{{this}\mspace{11mu} x},L}}} )}{t_{{this}\mspace{11mu} x}^{\prime}}}} & (3) \\{{\Phi_{L}( {TIS}_{0} )} > {1 - {\frac{D_{\min,L}}{t_{{this}\mspace{11mu} x}^{\prime}} \cdot {{floor}( \frac{D_{{{this}\mspace{11mu} x},L} - D_{{{this}\mspace{11mu} x},L}^{\prime}}{D_{\min,L}} )}}}} & (4)\end{matrix}$

-   -   -   x={year, month, week, day, hour}        -   t′_(this x)—[time: minutes]—time remaining in calendar            interval x. For example, at 45 minutes past an hour, there            are 15 minutes remaining prior to the end of this hour            interval.        -   floor( )—function that rounds the operand down to the next            smaller integer.

    -   Constraints that state the maximum number of events and total        duration of events that are permitted during continuous        “trailing” intervals (e.g., within interval durations that are        not aligned with “calendar” months, days, etc.) create multiple        conditions of the types shown in equations 5 and 6, all of which        should be met by a valid threshold TIS.

$\begin{matrix}{{\Phi_{L}( {TIS}_{0} )} > {1 - \frac{D_{x,L}( {N_{x,L}/N_{x,L}^{\prime}} )}{t_{x}}}} & (5) \\{{\Phi_{L}( {TIS}_{0} )} > {1 - {\frac{D_{\min,L}}{t_{x}} \cdot {{floor}( \frac{D_{x,L} - D_{x,L}^{\prime}}{D_{\min,L}} )}}}} & (6)\end{matrix}$

-   -   t_(x)—[time: minutes]—length of the interval over which        criterion is being addressed (e.g., one year, one month, one        week, one day, one hour).    -   The minimum TIS₀ that satisfies equation 3 through 6 for a        response level L is designated as TIS_(threshold, L).    -   3. Update the advisory control signal time series for this        system of assets. The TIS_(threshold, L) values assessed in the        previous step are now compared to the filtered average current        TIS, which are computed as in equation 7 for each IST interval.        In short, equation 7 says that those TIS intervals that are        shorter than D_(min) are averaged, and those TIS intervals that        are longer than D_(min) are used directly. While this function's        approach is workable without this filtering, the filtering of        equation 7 may help the implementer avoid responding to certain        spurious, short-lived events.        TIS_(filtered,n,L)=mean(TIS_({all n})(IST_(n)≤IST_({all n})<IST_(n)        +D _(min,L)))  (7)        -   If any TIS_(filtered,n,L) exceeds the threshold that was            established in the prior step, an ongoing event has not            lasted D_(min,L), and the allowed event counts N_(L) or            allowed total event durations D_(L) are not exceeded, an            event should be planned for the affected IST intervals, the            event counters and event durations should be updated            accordingly, and an advisory control signal and change in            average power should be planned or predicted for a future            interval n as in equation (8).            IF(TIS_(filtered,n,L)>TIS_(threshold,n,L) OR(D            _(event,n,L)≠0 AND D _(event,n,L) <D _(min,L)))            AND(D′ _(this x,n,l) +D _(min,L) −D _(event,n,L) ≤D            _(this x,L))            AND(D′ _(x,n,L) +D _(min,L) −D _(event,n,L) ≤D _(x,L))            AND(N′ _(this x,n,L) <N _(this x,L))            AND(N′ _(x,n,L) <N _(x,L))            AND(D′ _(this x,n,L)+(IST_(n+1)−IST_(n))≤D _(this x,L))            AND(D′ _(x,n,L)+(IST_(n+1)−IST_(n))≤D _(x,L))            THEN ACS_(n)=ACS_(L)            ELSE ACS_(n)=unchanged  (8)        -   Refer to Table 41 that lists the advisory control signals            candidates that may be planned for curtailable loads and            distributed generation according to the numbers of response            levels available from these assets. The algorithm is            complete for this update iteration.

TABLE 41 Example assignable advisory control signals for curtailableload and “dispatchable” distributed generation Number of AdvisoryControl Response Levels, K_(L) Signals ACS_(L) 1 0 (normal) 127(curtailed) 2 0 (normal) 64 (level 1) 127 (level 2) 3 0 (normal) 42(level 1) 84 (level 2) 127 (level 3) 4 Etc.

-   -   4. Predict Change in Average Power that Will Result from        Predicted Demand-Response Control Actions.        -   a. Tank Water Heaters. The typical daily pattern of            electrical energy consumption by residential tank water            heaters may be represented by look-up table or by function            of time of day. A look-up table has been appended. See            Appendix A. The total energy consumption represented in this            table should be represented as inelastic load; when            curtailments are planned, then all or part of the            represented load should be shown as elastic load by this            toolkit function. The magnitudes in the look-up table scale            with the number of tank water heaters represented and            controlled.    -   b. FIG. 60 is a graph 6000 showing a typical water heater power        consumption during week and weekend days.    -   c. Example: A full curtailment of 100 water heaters is presently        planned to occur from 13:50 until 14:30 this afternoon. Suppose        the IST intervals are 5-minutes long until 14:00 and 15-minutes        thereafter. Today is a Tuesday. First, if the inelastic load        from these water heaters has not already been addressed by        another function, the loads in the weekday columns for the hours        of the current IST time series may be multiplied by 100 and        allocated to the IST intervals that include them. (One may        interpolate the values of 5-minute intervals within the larger        15-minute intervals found in Subappendix A, but the        computational cost of this incremental improved accuracy may not        be worthwhile.) The water heater control system should be        assigned ACS=127 for these four predicted IST intervals        indicating a full curtailment is planned. Other ACS values will        be assigned as zero. Using Subappendix A, assign ΔL(13:50)=30.8        kW, ΔL(13:55)=30.8 kW, ΔL(14:00)=33.2 kW, and ΔL(14:15)=31.3 kW.    -   d. Thermostatic Space Conditioning.        -   Input parameters: C, K_(P), U, T_(OSP)(T_(center), K₁, t₁,            K₂, t₂), K_(S), η_(h), η_(c)        -   Other inputs that should be automated by function: K_(DRP),            ΔT_(DRSP), T_(o), P_(S)(I_(ave), t_(sr), t_(ss))        -   A simple dynamic model can be used to predict the energy            that will be consumed by a population of residences            controlled by demand-responsive thermostats or space            conditioning equipment. (This strategy will be so generic            that it should be applicable also to commercial thermostatic            space conditioning loads.) The dynamic model should (1)            predict the inelastic load from the building population            relatively well using few readily available predicted            weather effects like outdoor temperature and solar            insolation, (2) model the first-order dynamics of thermal            energy storage of the building population, (3) approximate            the effects of daily thermostatic occupancy settings and            cycles, (4) accommodate the planning of various            demand-response temperature setbacks and/or power cycling,            and (5) predict with reasonable accuracy any changes in            electrical energy consumption for periods when            demand-response events occur (e.g., the change in elastic            load).        -   This function uses a first-order dynamic model (see            equation 9) for the electrical energy used to heat or cool a            population of buildings. The electrical power is estimated            as the power used to make a representative indoor            temperature track a set point temperature that may be            affected by a pattern of occupancy settings and changes in            the set point that may be caused by demand response. A            single mass is cooled or heated and gains or loses energy            through a representative insulation.        -   The following formulation maintains meanings of many            parameters that will be recognized by buildings experts.            Some, but not all, of the parameters should be scaled to            represent the population of multiple buildings.

$\begin{matrix}{\frac{d\; T_{i}}{d\; t} = {{{- \frac{1}{C}} \cdot ( {{K_{DRP} \cdot K_{P}} + U} ) \cdot T_{i}} + {\frac{1}{C} \cdot ( {{K_{DRP} \cdot K_{P} \cdot ( {T_{OSP} + {\Delta\; T_{DRSP}}} )} + {U \cdot T_{o}} + {K_{S} \cdot P_{S}}} )}}} & (9)\end{matrix}$

$\frac{{dT}_{i}}{dt}$

-   -   -   -   —[° C./hour]—rate of change of the representative                interior temperature T_(i)            -   T_(i)—[° C.]—representative interior temperature            -   C—[kWh/° C.]—effective thermal mass (heat capacity) of                the building population.            -   Parameter C may be initially estimated based on a rule                of thumb for wood stick construction and furniture                contents: 2.0 Btu/° F.-ft² (1.1×10⁻³ kWh/° C.-m²)                normalized to floor space area. If a typical home has                150 m² floor area, then the thermal mass of this                building would be about 0.17 kWh/° C. One thousand such                homes would have an effective thermal mass of 170                kWh/° C. An initial estimate may be improved after data                becomes available for the given modeled building                population. See Appendix D.            -   U—[kW/° C.]—representative rate of thermal leakage from                the population of modeled buildings as a function of                difference between representative interior temperature                T_(i) and outside temperature T_(o). This number is                physically based on insulation R-values and total                building surface areas. An effective estimate might be                obtained recognizing that virtually all heating and                cooling energy is eventually lost, in which case this                parameter is approximately the total energy of space                conditioning and solar insolation divided by total                heating and cooling degree-day-hours.            -   Numbers near 0.021 kW/° C. per residential building and                0.21 kW/° C. per commercial building should be expected,                so these estimates may be multiplied by the numbers of                buildings of each type in the modeled population as an                initial estimate of parameter U. See appendix D.            -   K_(P)—[kW/° C.]—feedback parameter that represents the                magnitude of heating and cooling equipment power P that                will be active based on the difference between interior                temperature T_(i) and its target set point                T_(OSP)+ΔT_(DRSP). See equation 10. Electrical power                will be stated in this formulation as a function of                heating and cooling equipment power P.            -   Until this parameter can be learned from and fit to an                actual building population, it may be estimated by                multiplying the number of residential buildings using a                default value of 0.25 kW/° C. for a residential building                and perhaps 10 times as much for a commercial building.                See Appendix D.                P≡K _(DRP) ·K _(P)·((T _(OSP) +ΔT _(DRSP))−T _(i))  (10)            -   K_(DRP)—[dimensionless]—fraction that represents effects                of demand responses that result in cycling of the space                conditioning equipment. For example, if a response level                causes air conditioners to cycle at 50% duty cycle, a                factor equal to, or more than, 0.5 should be used for                K_(DRP) while the demand response is active. In                practice, the effect is less due to oversized equipment,                and the value of K_(DRP) will be found to be                considerably larger than the duty cycle. K_(DRP) is                unity 1.0 at times that no demand response cycling is                active. This parameter is specific to the thermostat                program and selected thermostat capabilities. (The duty                cycle is the fraction of time that the equipment is                permitted to operate. (That is, unity minus the fraction                of time the equipment is curtailed.) The parameter                K_(DRP) is similar to the duty cycle, but it is not                linearly or functionally related. If a relationship is                to be stated, declare K_(DRP) as the positive square                root of the fractional duty cycle D. This relation maps                D=0 to K_(DRP)=0, and it maps D=1 to K_(DRP)=1. In the                range D=[0,1], it maps D to a K_(DRP) that is larger                than D.

D K_(DRP) 0.0 0.0 0.25 0.50 0.50 0.71 0.75 0.87 1.0 1.0

-   -   -   -   T_(OSP)—[° C.]—effective interior temperature setpoint                that includes the daily effects of occupancy set points.                This should be set as the representative interior                temperature that the populations of buildings would                track as its members move between sleep, away, home, and                other occupancy settings. See Appendix C for an example                occupancy temperature setting time series that may be                used as a starting point for this time series.            -   ΔT_(DRSP)—[° C.]—effective change in interior set point                temperature for a population of buildings given a                planned response level. The setback temperature change                may be identical to an actual temperature setback, but                it is not necessarily identical to an actual setback.                This setback temperature is a feature unique to the                utility program and the capabilities of the vendors'                products and should be determined for a period during                which a response level is planned. Temperature changes                are expected to be plus or minus 1-5° C.            -   T_(o)—[° C.]—representative outdoor temperature that has                been obtained from the National Weather Data Service or                similar source. This is an input that should be                forecasted. It is preferable that this toolkit function                automate the retrieval of forecasted temperature, using                coordinates or nearest town or airport as an input.            -   K_(S)·P_(S)—[kW/° C.]—effective total incident solar                power on the building population, where P_(S) is the                predicted solar power density [kW/m²], and K_(S) is a                factor that accounts for the physical characteristics                and total areas of glazing and other building surfaces.                See Appendix B for an approach by which this product may                be predicted for any minute of a day.

        -   The electrical power may then be related to the heating and            cooling power P, taking into account the efficiency η of the            space-conditioning equipment, as shown in equation 11.            Heating and cooling power P was defined in equation 10. See            Appendix E for example scenarios under which electrical            power has been simulated by this model with its default            values.

$\begin{matrix}\begin{matrix}{{P_{e} = {\frac{1}{\eta_{h}}{P}}},} \\{{{if}\mspace{14mu} T_{i}} < {T_{OSP} + {\Delta\; T_{DRSP}}}} \\{{P_{e} = {\frac{1}{\eta_{c}}{P}}},} \\{{{if}\mspace{14mu} T_{i}} > {T_{OSP} + {\Delta\; T_{DRSP}}}}\end{matrix} & (11)\end{matrix}$

-   -   -   -   η_(h)—[dimensionless]—effective electrical conversion                efficiency that relates heating power to expended                electrical power (default value=1.0).            -   η_(c)—[dimensionless]—effective electrical conversion                efficiency that relates cooling power to expended                electrical power (default value=1.3).

        -   This formulation has treated state variables and inputs as            continuous time variables, but one may solve for the            predicted electrical power for discrete time intervals n,            provided that the time intervals are short with respect to            the buildings' thermal response time. (For example, discrete            time intervals Δt from 1 to 5 minutes can be used. Several            iterations might be used for IST intervals that are longer            than 5 minutes. Where an IST interval duration is longer            than the solution interval Δt, the electrical power            solutions P_(e) within an IST interval should be averaged to            obtain the respective average inelastic load or elastic            change in electrical load.) Equation 12 is a discretized            version of equation 9 that may be used to predict the state            variable T_(i) after each interval n of length Δt.

$\begin{matrix}{{\Delta\;{T_{i}(n)}} = {{\lbrack {1 - {\frac{1}{C} \cdot ( {{{K_{DRP}(n)} \cdot K_{P}} + U} ) \cdot {T_{i}(n)}} + {\frac{1}{C} \cdot ( {{{K_{DRP}(n)} \cdot K_{P} \cdot ( {{T_{OSP}(n)} + {\Delta\;{T_{DRSP}(n)}}} )} + {U \cdot {T_{o}(n)}} + {K_{S} \cdot {P_{S}(n)}}} )}} \rbrack \cdot \Delta}\;{t(n)}}} & (12)\end{matrix}$

-   -   -   State variable T_(I)—the representative interior            temperature—may be updated after each discrete time interval            using equation 13.            T _(i)(n+1)=T _(i)(n)+ΔT _(i)(n)  (13)        -   The solution should be completed twice: In the first case,            no demand response is modeled. Both K_(DRP) and ΔT_(DRSP)            should be set to zero for intervals of case 1. The resulting            electrical power P_(e) is the inelastic load predicted where            the space conditioning equipment is not responsive to an            incentive signal and no demand response occurs. In the            second case, either or both K_(DRP) and ΔT_(DRSP) are            assigned for intervals during which demand responses have            been planned. If demand responses have been planned, the            solutions for electrical power P_(e) will differ by the            change in elastic load, which is an output of this function            expected by the toolkit framework.            ΔL _(elastic)(n)=P _(e,case #1)(n)−P _(e,case #2)(n)  (14)

    -   e. Smart Appliances and other Loads. The list of appliances and        devices that could become controlled is diverse. Simplifications        is necessary until proper models of these loads can be        completed. The daily patterns for plug loads and other devices        may be learned over time if adequate measurements are being        made. Until then, hourly load profiles for most of the other        residential loads are provided in Subappendix H.

Further Alternatives:

-   -   1. The extreme parts of TIS distribution curves should be fitted        to a smooth monotonic function. There is some concern that        event-driven demand response may be allowed so infrequently that        it will be difficult to assign accurate thresholds on TIS.    -   2. While this function has been targeted toward events that        happen at relatively high TIS values, this general approach is        equally valid for infrequent events that occur at very low TIS        values when energy appears to be a great bargain. Today, few        commercially available demand-responsive assets are able to        provide this valuable response.    -   3. The lookup table of Subappendix A is simple to use, but it        does not correctly predict rebound effects that might be        important for peak load management. When water heaters are        released from their curtailed operation, they consume heavily to        reheat the cooled water volume. In some cases, this rebound will        create a new, undesirable peak. Implementers can also use        physics-based models of water heaters that include effects of        thermal energy storage and customer water consumption.        -   An approach similar to the space conditioning model yields            the difference equations 15 and 16 for a population of water            heaters. The parameters of the difference equations may, in            principle, be determined by fitting the modeled            representative water heater power P_(WH)(n) during each            interval n to the observed average power shown in            Subappendix A.

$\begin{matrix}{{T_{WH}( {n + 1} )} = {{( {1 + \frac{{{W(n)} \cdot \Delta}\;{t(n)}}{V_{WH}} - \frac{{{K_{DR}(n)} \cdot K_{P} \cdot \Delta}\; t_{n}}{V_{WH} \cdot C_{W}}} ) \cdot {T_{WH}(n)}} + {\frac{{{K_{DR}(n)} \cdot K_{P} \cdot \Delta}\;{t(n)}}{V_{WH} \cdot C_{W}} \cdot T_{SP}} - {\frac{{{W(n)} \cdot \Delta}\;{t(n)}}{V_{W}} \cdot T_{i}}}} & (15) \\{\mspace{79mu}{{P_{WH}(n)} \equiv {K_{P}( {T_{SP} - {T_{WH}(n)}} )}}} & (16)\end{matrix}$

-   -   -   T_(WH)(n)—[° C.]—representative temperature of water stored            in this population of water heaters at the beginning of            interval n.        -   W(n)—[m³/h]—rate of water consumed by the water heaters            during interval n.        -   K_(DR)(n)—[dimensionless]—representative impact of a            demand-response cycling program on the representative water            heater power P_(WH). At most times, this variable is equal            to 1.0. During full curtailment of water heaters, this            variable is equal to 0.0. If the water heaters are randomly            cycled with an available duty cycle of 50%, the this            variable would be a number between 0.5 and 1.0, which number            should be determined and fit by theory or observation.        -   K_(P)—[kW/° C.]—representative ratio of water heater power            to the difference between the water heaters' representative            temperature set point, as is shown in equation 16.        -   Δt(n)—[h]—duration of interval n.        -   V_(WH)—[m³]—representative volume of water in the water            heaters.        -   C_(W)—[kWh/(m³·° C.)]—heat capacity of water.        -   T_(SP)—[° C.]—representative thermostat setpoint for the            modeled population of water heaters.        -   T_(I)—[° C.]—typical temperature of cold water entering the            water heaters.

    -   4. The approach to predicting thermostatic space conditioning        loads may be improved in many ways:        -   a. Curve fitting and adaptive algorithms may be developed or            employed to improve the parameters and more accurately model            the given population of buildings. Specifically, the            historical errors between actual and predicted electrical            energy consumption by the population of space conditioning            loads may be used to estimate parameters via least squares.            The parameters to be estimated include constants K_(p), U,            C, and K_(S). Parameter T_(OSP)(t) should be treated as a            function of time-of-day. K_(S)(t) may also be treated as a            function of time-of-day, in which case it might represent            the effects of incident angle of solar power on various            building surfaces.        -   b. Additional inputs may be employed to improve the accuracy            of the model. For example, wind and humidity predictions may            be useful to improve the model's accuracy.        -   c. Higher-order state models may be employed to address            observed dynamic inaccuracies. However, remember that the            states that are meaningful for modeling individual buildings            may not be so useful in an aggregated building model.        -   d. As drafted, the building model is equally applicable to            both heating and cooling. Care should be taken where methods            of heating and cooling are asymmetrical in the modeled            buildings. Different electrical efficiencies η_(h) and η_(c)            have been recommended, but there may also be cause to            distinguish P_(h) and P_(c) if the effective powers of            heating and cooling are different.

SUBAPPENDIX A Daily Water Heater Consumption Patterns for Week andWeekend Days in the Pacific Northwest Time Weekday Weekend (hh:mm) (kW)(kW)  0:00 0.122 0.128  0:15 0.151 0.128  0:30 0.130 0.130  0:45 0.1070.108  1:00 0.103 0.106  1:15 0.113 0.111  1:30 0.113 0.099  1:45 0.0980.097  2:00 0.089 0.098  2:15 0.093 0.105  2:30 0.099 0.100  2:45 0.0890.097  3:00 0.135 0.120  3:15 0.098 0.104  3:30 0.164 0.117  3:45 0.1290.106  4:00 0.239 0.209  4:15 0.183 0.161  4:30 0.240 0.205  4:45 0.2660.170  5:00 0.401 0.247  5:15 0.427 0.277  5:30 0.460 0.295  5:45 0.5420.302  6:00 0.700 0.410  6:15 0.708 0.420  6:30 0.743 0.522  6:45 0.7640.530  7:00 0.817 0.640  7:15 0.785 0.622  7:30 0.738 0.640  7:45 0.7130.634  8:00 0.716 0.736  8:15 0.687 0.734  8:30 0.672 0.710  8:45 0.6360.696  9:00 0.615 0.704  9:15 0.584 0.695  9:30 0.563 0.670  9:45 0.5180.647 10:00 0.467 0.624 10:15 0.466 0.616 10:30 0.454 0.595 10:45 0.4310.567 11:00 0.415 0.543 11:15 0.409 0.549 11:30 0.395 0.527 11:45 0.3850.521 12:00 0.380 0.481 12:15 0.365 0.475 12:30 0.355 0.450 12:45 0.3490.438 13:00 0.347 0.435 13:15 0.328 0.411 13:30 0.319 0.389 13:45 0.3080.380 14:00 0.332 0.403 14:15 0.313 0.401 14:30 0.304 0.380 14:45 0.3140.374 15:00 0.324 0.455 15:15 0.325 0.434 15:30 0.345 0.432 15:45 0.3490.426 16:00 0.385 0.459 16:15 0.396 0.458 16:30 0.407 0.443 16:45 0.4200.440 17:00 0.452 0.462 17:15 0.461 0.463 17:30 0.467 0.457 17:45 0.4540.458 18:00 0.513 0.467 18:15 0.521 0.472 18:30 0.543 0.465 18:45 0.5640.470 19:00 0.606 0.462 19:15 0.588 0.440 19:30 0.613 0.422 19:45 0.5940.407 20:00 0.606 0.439 20:15 0.590 0.430 20:30 0.592 0.407 20:45 0.5510.384 21:00 0.525 0.393 21:15 0.486 0.370 21:30 0.436 0.342 21:45 0.3750.307 22:00 0.326 0.285 22:15 0.288 0.257 22:30 0.244 0.235 22:45 0.2070.209 23:00 0.183 0.191 23:15 0.163 0.174 23:30 0.149 0.165 23:45 0.1360.145

Subappendix B: Example Approximation of Effective Incident Solar PowerK_(S)·P_(S)

Input parameters: B_(res), B_(com)

Inputs that should be obtained automatically by function (e.g., byinternet): I_(ave), t_(sr), t_(ss)

The following approach will produce reasonable dynamics to represent theeffect of solar insolation on building populations, but it does not relyon actual predicted insolation nor on actual building data and buildingconstruction properties. As time permits, this approach may be improvedto better predict building performance.

-   -   For the day to be modeled at this location, look up sunrise        (t_(sr)), sunset (t_(ss)), and average insolation (I_(ave)).        This input information may be found at        http://aom.giss.nasa.gov/srlocat.html, for example, if one        enters the month, latitude, and longitude.    -   Estimate K_(S). First estimate the total square meters of        building floor space being modeled. This can be roughly        estimated by multiplying the number of modeled residences by        175, and the number of commercial buildings by 2000. The floor        space will be multiplied by 7% to represent the effects of        glazing and imperfectly reflecting wall and roof surfaces. The        product of floor space and 0.07 estimates K_(S) as shown in        equation B1.        K _(S)=0.07·(175·B _(res)+2000·B _(com))  (B1)        -   K_(S)—[m²]—estimated effective building surface area that is            exposed to insolation. This parameter accounts for overall            reflectivity, glazing surfaces, and orientation. It is            assumed that this parameter is not a function of time.        -   B_(res)—[count]—number of residential buildings in modeled            population. This is a very gross attempt to scale the impact            of insolation based on the number of buildings and based on            a typical floorspace of represented buildings. The factor            175 may be improved if better information is known about            typical residential buildings that are in this population of            residential buildings.        -   B_(com)—[count]—number of commercial buildings in modeled            population. This is a very gross attempt to scale the impact            of solar insolation based on the number of buildings and            based on a typical floorspace of represented buildings. The            factor 2000 may be improved if better information is known            about typical residential buildings that are in this            population of commercial buildings.    -   Estimate P_(S)(t). A sinusoidal pattern is assumed for the        insolation through a day between sunrise and sunset.

$\begin{matrix}{{P_{S}(t)} = \{ \begin{matrix}{\frac{1440 \cdot I_{ave}}{t_{ss} - t_{sr}} \cdot ( {1 - {\cos( \frac{{( {t - t_{sr}} ) \cdot 2}\;\pi}{t_{ss} - t_{sr}} )}} )} & {t_{sr} \leq t \leq t_{ss}} \\0 & {otherwise}\end{matrix} } & ({B2})\end{matrix}$

-   -   -   P_(S)(t)—[W/m²]—insolation as a function of time of day.        -   I_(ave)—[W/m²]—average insolation for this day (over 24            hours/1440 minutes) at this location from            http://aom.giss.nasa.gov/sriocat.html, or similar source of            information. This number is multiplied by the number of            minutes in a day in equation B2 to state the total            insolation expected to be received this day.        -   t—[minutes]—time-of-day represented in minutes. For example,            the time 7:06 should be represented in this function by 426            minutes=7*60+6.        -   t_(sr)—[minutes]—minute of this day on which sunrise occurs.            Care should be taken to address UTC time and daylight            savings properly.        -   t_(ss)—[minutes]—minute of this day on which sunset occurs.            Care should be taken to address UTC time and daylight            savings properly.

An example profile 6100 of P_(S)(t) is shown in FIG. 61 for a day onwhich t_(sr)=7:06 (426 minutes into the day), t_(ss)=17:13 (1033 minutesinto the day), and l_(ave)=201 W/m².

Subappendix C: Example Approach for Smooth Approximation of OccupancySet Point Temperature TOSP(t)

Input parameters: T_(center), K₁, t₁, K₂, t₂

Input variable: t

The occupancy set point temperature T_(OSP) reflects a representativechange in the target interior temperature set point that is induced bybuilding occupants as they schedule or manually change theirthermostatic set points for periods of the day. The following approachproduces a smooth function of time-of-day while using only a fewsupplied input parameters.

$\begin{matrix}{{T_{OSP}(t)} = {T_{center} + {K_{1} \cdot {\sin( \frac{2\;{\pi \cdot ( {t + t_{1}} )}}{1440} )}} + {K_{2} \cdot {\sin( \frac{4\;{\pi \cdot ( {t + t_{2}} )}}{1440} )}}}} & ({C1})\end{matrix}$

-   -   T_(OSP)(t)—[° C.]—occupancy set point temperature as a function        of time of day t.    -   T_(center)—[° C.]—input temperature to this function that        represents the center of a sinusoidal function. See Table 42 for        example default values.    -   K₁—[° C.]—input parameter that represents a diurnal magnitude of        temperature variation. See Table 42 for example default values.    -   t—[time: minutes]—time of day represented as minutes since the        previous midnight. The number 1440 represents a full day cycle        period of minutes t.    -   t₁—[time: minutes]—input parameter that represents a phase        offset of the diurnal magnitude of temperature variation. See        Table 42 for example default values.    -   K₂—[° C.]—input parameter that represents a magnitude of        temperature variation that occurs at twice the diurnal frequency        (e.g., two full periods per day). See Table 42 for example        default values.    -   t₂—[time: minutes]—input parameter that represents a phase        offset of the diurnal magnitude of temperature variation. See        Table 42 for example default values.

The example input parameters of Table 42 are based on expert opinion andshould suffice until data is found to refine these parameters. (It isalso acceptable to simply use a constant value T_(center), similar towhat has been recommended in Table 42 for summer and fall periods.)

TABLE 42 Five input parameters that may be used to specify the occupancyset point temperature T_(OSP)(t) by season of year T_(center) K₁ t₁ K₂t₂ (° C.) (° C.) (minutes) (° C.) (minutes) winter 20.0 0.5 −450 0.8 360spring 21.5 0.0 — 0.0 — summer 23.0 0.2  270 0.5 180 fall 21.5 0.0 — 0.0—

FIG. 62 is a plot 6200 of a winter profile of T_(OSP)(t) that uses thewinter parameters of Table 42. FIG. 63 is a plot 6300 of a summerprofile of T_(OSP)(t) that uses the summer parameters of Table 42.

Subappendix D: Additional Insights Concerning the Parameters Used toModel Thermostatic Control of Buildings

There are several terms of equation (9) that are useful toward theunderstanding of relationships between the model parameters.

Thermal Losses

If the effects of space conditioning and solar insolation wereeliminated, the relationship of equation D1 would remain and woulddescribe the asymptotic migration of the representative temperatureT_(i) toward the ambient outdoor temperature T_(o) that is characterizedby the relationship between thermal losses U and thermal mass C.

$\begin{matrix}{\frac{d\; T_{i}}{dt} = {\frac{U}{C} \cdot ( {T_{o} - T_{i}} )}} & ({D1})\end{matrix}$

An insight available from equation D1 is that it defines a relaxationtime constant as the ratio C/U. The time constant is the time that itwould take for the two temperatures to come within about 37% of thestarting difference between the two temperatures. For example, if theinterior temperature begins at 20° C. and the outside temperatureremains constant at 0° C., the time constant would be the time it takesfor the interior temperature to drop to 7.4° C. If that amount of timeis estimated to be 8 hours, then the magnitude of parameter C should be8 times as great as the magnitude of U. Therefore, if the value of C isestimated to be 0.17 kWh/° C. for a residential building, then the valueof U should be approximately 0.021 kW/° C., which is the recommendeddefault value for this parameter.

Space Conditioner Size and Responsiveness

If the effects of solar insolation and thermal losses may be temporarilyignored, equation D2 may be derived from equation 9 to represent therate at which the representative heating or cooling equipment wouldcorrect the representative interior temperature T_(i) toward its setpoint, which is the sum T_(OSP)+ΔT_(DRSP).

$\begin{matrix}{\frac{d\; T_{i}}{d\; t} = {\frac{K_{DRP} \cdot K_{P}}{C}( {T_{OSP} + {\Delta\; T_{DRSP}} - T_{i}} )}} & ({D2})\end{matrix}$

In the normal case, K_(DRP) is unity.

Equation D2 is characterized by a time constant as the ratio C/K_(P).Space conditioning equipment is usually sized to correct the interiortemperature in a relatively short time. If, for example, buildingsheaters were to heat a residential building and its contents from 10° C.to 20° C., it might take about 40 minutes to heat those contents fullyto 16.3° C. Therefore, the magnitude of C should be about 0.67 that ofK_(P). If C is 0. 17 kWh/° C. for a residential building, then therepresentative magnitude of K_(P) should be about 0.25 kW/° C., which isthe recommended default value for this parameter.

Average Electrical Power for Space Conditioning

Another insight may be obtained if one calculated the final, constantcondition of how much power it would take to maintain a thermostatic setpoint for a given outdoor temperature T_(o). One may calculate a finalinterior temperature T_(i) using equation 9. Then this interiortemperature may be used in equations 10 and 11 to predict that resultingelectrical power P_(e) that would be consumed.

Ignoring the effects of solar insolation and setting K_(DRP) to unity,the steady-state electrical power is given by equation D3.

$\begin{matrix}{P_{e} = {\frac{1}{\eta} \cdot ( \frac{U \cdot ( {T_{OSP} + {\Delta\; T_{DRSP}} - T_{o}} )}{1 + \frac{U}{K_{P}}} )}} & ({D3})\end{matrix}$

For present purposes, equation D3 should be used to test thereasonableness of the set of parameters. Given the sets of defaultparameters recommended so far for a residential building, and assumingefficiency η of the electrical conversion and ΔT_(DRSP) are unity, itwould take about 190 average watts to maintain a constant 10° C.difference between the set point and ambient outdoor temperatures inthis structure.

Subappendix E: Example Electrical Power Profile Cases from ThermostaticModel with Default Winter Parameter

FIG. 64 is a graph 6400 of the predicted electrical power consumptionfor 1000 thermostatically controlled residential buildings whereT_(o)=10° C. FIG. 65 is a graph 6500 of the predicted electrical powerconsumption for 1000 thermostatically controlled residential buildingswhere T_(o)=0° C. FIG. 66 is a graph 6600 of the predicted electricalpower consumption for 1000 thermostatically controlled residentialbuildings where T_(o)=0° C.; ΔT_(DRSP)=−2° C. from 8:00 to 10:00 am.FIG. 67 is a graph 6700 of the predicted electrical power consumptionfor 1000 thermostatically controlled residential buildings whereT_(o)=0° C.; K_(DRP)=0.75 from 8:00 to 10:00 am.

Subappendix F: Pseudo Code (for caldendar events only) FOR everyresponse level L (excluding L = 0)  [Establish statistical distributionof TIS₀]  Δ$ = $0.001/kWh  TIS_(0,min) = −$3/kWh  TIS_(0,max) = +$3/kWh Ψ = {TIS_(0,min),TIS_(0,min) + Δ$,TIS_(0,min) + 2 · Δ$,...,TIS_(0,max)− Δ$}  FOR all k historical {IST₀,TIS₀} pairs   TIS_(0,k,mean) =mean(TIS₀(IST_(0,k) − D_(min,L) < IST₀ ≤ IST_(0,k)))     WHERE D_(min,L)is the minimum duration for any event at     response level L  END FOR FOR all k   IF TIS_(0,b) ≤ TIS_(0,k,mean) < TIS_(0,b) + Δ$, WHERETIS_(0,b) ∈ Ψ THEN    DIST_(L)(TIS_(0,b))= DIST_(L)(TIS_(0,b))+1   ENDIF  END FOR  ${\Phi_{L}( {TIS}_{0,b} )} = \frac{\sum\limits_{i = {TIS}_{0,\min}}^{{TIS}_{0,b}}\;{{DIST}_{L}(i)}}{\sum\limits_{i = {TIS}_{0,\min}}^{{TIS}_{0,\max} - {\Delta\$}}\;{{DIST}_{L}(i)}}$END FOR [Initialize iteration index m] m = 0 FOR every new {IST,TIS}series (including relaxation instances):  IF new update interval THEN  m = m + 1  ELSE [IF relaxation instance]   m = m  END IF IST_({all n},m) = IST_({all n},new series)  TIS_({all n},m) =TIS_({all n}, new series)  [Initialize ACS]  ACS_({all n},m) = 0  FORevery response level L, in ascending order (excluding L = 0)   [UpdateDIST_(L)(TIS₀) and Φ_(L)(TIS₀)]   TIS_(0,mean) = mean(TIS₀(IST_(0,m) −D_(min,L) < IST₀ ≤ IST_(0,m)))   IF TIS_(0,b) ≤ TIS_(0,mean) <TIS_(0,b) + Δ$, WHERE TIS_(0,b) ∈ Ψ THEN    DIST_(L)(TIS_(0,b)) =DIST_(L)(TIS_(0,b))+1   END IF   ${\Phi_{L}( {TIS}_{0,b} )} = \frac{\sum\limits_{i = {TIS}_{0,\min}}^{{TIS}_{0,b}}\;{{DIST}_{L}(i)}}{\sum\limits_{i = {TIS}_{0,\min}}^{{TIS}_{0,\max} - {\Delta\$}}\;{{DIST}_{L}(i)}}$FOR intervals n = 0 to 55  [Filter TIS]  TIS_(filtered,n,m,L) =mean(TIS_({all n})(IST_(n,m) ≤ IST_({all n},m) < IST_(n,m) + D_(min,L)))  IF n = 0 THEN [time space]   If relaxation instance THEN   D_(event,0,m,L) = D_(event,0,m,L)    D′_(this x,0,m,L) =D′_(this x,0,m,L)    N′_(this x,0,m,L) = N′_(this x,0,m,L)     WHERE x ={year, month, week, day, hour} and “this” refers to     calendar periods  ELSE [IF new update interval]    [Update event duration in time space]   IF ACS_(0,m−1) = ACS_(L) THEN     D_(event,0,m,L) =D_(event,0,m−1,L) + (IST_(0,m) − IST_(0,m−1))    ELSE    D_(event,0,m,L) = 0    END IF    [Update calendar x cumulative eventduration(s) and count(s) in    time space]    IF change(x, IST_(0,m−1),IST_(0,m)) THEN     D′_(this x,0,m,L) = 0     N′_(this x,0,m,L) = 0   ELSE IF ACS_(0,m−1) = ACS_(L) THEN     D′_(this x,0,m,L) =D′_(this x,0,m−1,L) + (IST_(0,m) − IST_(0,m−1))     N′_(this x,0,m,L) =N′_(this x,0,m−1,L)    ELSE IF ACS_(0,m−1) ≠ ACS_(L) AND ACS_(0,m−2) =ACS_(L) THEN     D′_(this x,0,m,L) = D′_(this x,0,m−1,L)    N′_(this x,0,m,L) = N′_(this x,0,m−1,L) + 1   ELSE    D′_(this x,0,m,L) = D′_(this x,0,m−1,L)     N′_(this x,0,m,L) =N′_(this x,0,m−1,L)    END IF   END IF  ELSE [IF n = 1 to 55] [futurespace]   [Update event duration in future space]   IF ACS_(n−1,m) =ACS_(L) THEN    D_(event,n,m,L) = D_(event,n−1,m,L) + (IST_(n,m) −IST_(n−1,m))   ELSE    D_(event,n,m,L) = 0   END IF   [Update calendar ×cumulative event duration(s) and count(s) in   future space]   IFchange(x,IST_(n−1,m), IST_(n,m)) THEN    D′_(this x,n,m,L) = 0   N′_(this x,n,m,L) = 0   ELSE IF ACS_(n−1,m) = ACS_(L) THEN   D′_(this x,n,m,L) = D′_(this x,n−1,m,L) + (IST_(n,m) − IST_(n−1,m))   N′_(this x,n,m,L) = N′_(this x,n−1,m,L)   ELSE IF n ≠ 1 ANDACS_(n−1,m) ≠ ACS_(L) AND ACS_(n−2,m) = ACS_(L)   THEN   D′_(this x,n,m,L) = D′_(this x,n−1,m,L)    N′_(this x,n,m,L) =N′_(this x,n−1,m,L) + 1   ELSE      D′_(this x,n,m,L) =D′_(this x,n−1,m,L)      N′_(this x,n,m,L) = N′_(this x,n−1,m,L)     ENDIF    END IF    [Determine threshold(s)]    ${\Phi_{\alpha,{{this}\mspace{14mu} x},L} = {1 - \frac{D_{{{this}\mspace{11mu} x},L}( {1 - {N_{{{this}\mspace{11mu} x},n,m,L}^{\prime}/N_{{{this}\mspace{11mu} x},L}}} )}{t_{{{this}\mspace{11mu} x},n}^{\prime}}}},$    WHERE t′_(this x,n) = time remaining in this x at every IST_(n,m)   $\Phi_{\beta,{{this}\mspace{14mu} x},L} = {1 - {\frac{D_{\min,L}}{t_{{{this}\mspace{14mu} x},n}^{\prime}} \cdot {{floor}( \frac{D_{{{this}\mspace{14mu} x},L} - D_{{{this}\mspace{14mu} x},n,m,L}^{\prime}}{D_{\min,L}} )}}}$  TIS_(threshold,n,m,L) = min(TIS₀) such that Φ_(L) (TIS₀) >  max(Φ_(α,this x,L), Φ_(β,this x,L))|₀ ¹ for all x   [Determine ACS]  IF (TIS_(filtered,n,m,L) > TIS_(threshold,n,m,L) OR (D_(event,n,m,L) ≠0 AND   D_(event,n,m,L) < D_(min,L)))     AND (D′_(this x,n,m,L) +D_(min,L) − D_(event,n,m,L) ≤ D_(this x,L))     AND (N′_(this x,n,m,L) <N_(this x,L))     AND (D′_(this x,n,m,L) + (IST_(n+1,m) − IST_(n,m)) ≤D_(this x,L)) THEN     ACS_(n,m) = ACS_(L)    ELSE     ACS_(n,m) =ACS_(n,m)    END IF   END FOR [every n]  END FOR [every L] END FOR[every new {IST, TIS} series]

In the pseudocode, a set of lower boundaries of bins used to build upTIS₀ distribution.

It is acceptable to use a standard averaging window duringinitialization. This may be helpful if the initial TIS₀ distribution isto be shared among several load toolkit function implementations at thesame transactive node and/or used for response levels L within the sameimplementation. Note that m is used as an iteration index, so that m−1refers to the previous update interval. During a relaxation instance,IST₀ remains unchanged. Averaging TIS₀ may have little effect onupdating the TIS₀ distribution. If that is the case, the implementer maychoose not to do the averaging. This may then allow the update of TIS₀distribution to be done outside of any single toolkit functionimplementation to be shared among several toolkit functionimplementations at the same transactive node and/or used for responselevels L within the same implementation. D_(event) is a new variableintroduced to keep track of the duration of an event. change(x, t₁, t₂)”represents a function to determine whether calendar period x has changedbetween t₁ and t₂, inclusive.

Subappendix G: MATLAB Simulation Code and Results (for Calendar EventsOnly)

%% TKLD_2.4 MATLAB Simulation—Version E (matches pseudo code above)

% This script is to simulate the performance of load toolkit functionTKLD_2.4 using actual TIS data queried from the Netezza database

%

%% Clear everything to start new simulation:

clear all; close all; clc; tic

%% Subproject Configuration:

timezone=‘Pacific’; % ‘Pacific’ or ‘Mountain’

N_WH=800; % number of water heaters

K_L=1; % number of control levels

% K_L=2; % FOR TESTING (comment out above line)

subplot(2+K_L,1,K_L+2); stairs(IST_num(m,:),[Delta_Load(m,:)Delta_Load(m,56)]);

ylabel(“\DeltaL [kW]”);

x_tick_label=datestr(x_tick,‘mm/dd/yy HH:MM’);

set(gca,‘XTick’,x_tick,‘XTickLabel’,x_tick_label)

xlabel(‘IST_n’)

%% Simulation time in minutes:

sim_time=toc/60;

Example 1—One Response Level

Running the above MATLAB code, with K_(L)=1, D_(min,1)=15 min,D_(this day,1)=240 min, N_(this month,1)=5, D_(this month,1)=5×240min=1200 min, results in the plots 6800, 6900, 7000, 7100, 7200 of FIG.68 FIG. 69, FIG. 70, FIG. 71 and FIG. 72 FIG. 73, respectively. Plot7100 is in time space whereas plot 7200 is in future space.

Example 2—Two Response Levels

Running the above MATLAB code, with

-   -   K_(L)=2, D_(min,1)=120 min, D_(this day,1)=240 min,        N_(this month,1)=5, D_(this month,1)=5×240 min=1200 min,    -   D_(min,2)=15 min, D_(this day,2)=240 min, N_(this month,2)=5,        D_(this month,2)=5×240 min=1200 min,        results in the plots 7300, 7400, 7500, 7600, 7700 of FIG. 73,        FIG. 74, FIG. 75, FIG. 76, and FIG. 77, respectively. Plot 7600        is in time space whereas plot 7700 is in future space.

Subappendix H: Typical Hourly Residential Load Profiles

The load profiles in Table 43 are derived from normalized profiles insingle-family detached house models found at [H1] and yearly energyconsumed by each load computed from equations given in [H2]. Note that2400 ft² and 4 bedrooms were used to represent a “typical” single-familydetached house. In Table 43, MEL refers to miscellaneous electric loads.

[H1] U.S. Department of Energy, Building Energy Codes Program,Residential Prototype Building Models:http://www.energycodes.gov/development/residential/iecc_models

[H2] U.S. Department of Energy, Building Technologies Program, BuildingAmerica House Simulation Protocols, by R. Hendrom and C. Engbrecht(National Renewable Energy Laboratory), Available athttp://www.nrel.gov/docs/fy11osti/49246.pdf.

TABLE 43 Typical Hourly Residential Load Profiles [kW] CookingDishwasher Clothes Washer Clothes Dryer Hour Lighting Refrigerator RangeWeekday Weekend Weekday Weekend Weekday Weekend MELs 1 0.029 0.04730.011 0.0084 0.0090 0.0022 0.0027 0.032 0.039 0.396 2 0.029 0.0463 0.0110.0037 0.0040 0.0017 0.0021 0.019 0.024 0.365 3 0.029 0.0452 0.0060.0028 0.0030 0.0009 0.0011 0.013 0.016 0.360 4 0.029 0.0439 0.0060.0019 0.0020 0.0009 0.0011 0.006 0.008 0.355 5 0.086 0.0432 0.0110.0019 0.0020 0.0017 0.0021 0.013 0.016 0.342 6 0.179 0.0432 0.0170.0056 0.0060 0.0026 0.0032 0.019 0.024 0.381 7 0.201 0.0449 0.0390.0112 0.0120 0.0052 0.0064 0.051 0.063 0.441 8 0.179 0.0473 0.0680.0169 0.0181 0.0113 0.0138 0.102 0.125 0.468 9 0.079 0.0483 0.0730.0318 0.0341 0.0170 0.0208 0.156 0.191 0.396 10 0.054 0.0490 0.0770.0356 0.0381 0.0200 0.0245 0.220 0.270 0.337 11 0.054 0.0473 0.0680.0309 0.0331 0.0196 0.0240 0.252 0.309 0.345 12 0.054 0.0473 0.0790.0262 0.0281 0.0174 0.0213 0.263 0.321 0.345 13 0.054 0.0496 0.0900.0225 0.0241 0.0157 0.0192 0.240 0.293 0.339 14 0.054 0.0496 0.0730.0253 0.0271 0.0139 0.0170 0.218 0.266 0.351 15 0.054 0.0490 0.0700.0206 0.0221 0.0122 0.0149 0.196 0.240 0.371 16 0.093 0.0496 0.0900.0197 0.0211 0.0113 0.0138 0.186 0.227 0.391 17 0.201 0.0523 0.1470.0206 0.0221 0.0118 0.0144 0.179 0.219 0.463 18 0.279 0.0574 0.2390.0272 0.0291 0.0113 0.0138 0.175 0.215 0.562 19 0.376 0.0591 0.1860.0478 0.0512 0.0113 0.0138 0.167 0.204 0.610 20 0.451 0.0574 0.0960.0609 0.0652 0.0113 0.0138 0.164 0.201 0.630 21 0.459 0.0557 0.0560.0496 0.0532 0.0113 0.0138 0.169 0.207 0.652 22 0.315 0.0547 0.0390.0365 0.0391 0.0109 0.0133 0.175 0.215 0.636 23 0.176 0.0523 0.0250.0243 0.0261 0.0074 0.0091 0.141 0.172 0.551 24 0.072 0.0490 0.0170.0169 0.0181 0.0039 0.0048 0.077 0.094 0.479

Plots of load profiles given in Table 43 are shown in FIG. 78 throughFIG. 84. In particular, FIG. 78 is a plot 7800 of a lighting load. FIG.79 is a plot 7900 of a refrigerator load. FIG. 80 is a plot 8000 of acooking range load. FIG. 81 is a plot 8100 of a dishwasher load. FIG. 82is a plot 8200 of a clothes washer load. FIG. 83 is a plot 8300 of aclothes dryer load. FIG. 84 is a plot 8400 of a miscellaneous electricload.

6.3.11 Load Function—Non-Renewable Distributed Generation Event-DrivenDemand Response (Function 2.5)

Description:

This is a function for predicting the responses of distributedgenerators that only infrequently respond to events that may beidentified from an incentive signal. When these assets respond, theytransition to a limited number of available response levels, which inthis case are limited to two levels—standing idle or generating. Thisfunction was adapted quite directly from function 2.4 ResidentialEvent-Driven Demand Response), which includes certain details notrepeated here. Also refer to function 2.0 General Event-Driven DemandResponse for general guidance about event-driven toolkit functions.

It is assumed that the distributed generator is normally idle, so itsinelastic load prediction is zero. If this is not the case, or if thegenerator is used for objectives other than transactive control, thenthis toolkit function should be augmented to keep track of its inelasticload as a baseline to its generation under transactive control.Implementers may elect to also keep track of generator availability andscheduled testing periods, which conditions are not being tracked inthis function.

This function can respond to absolute or relative TIS as desired by anapplication. In Version 0.4, a new parameter is recommended to state theeffective cost of generation by this distributed generation resource.Because the TIS represents an economic signal, distributed generatorsthat are more expensive than the TIS should not be operated, regardlessof how the event periods have been determined.

This function was originally drafted for distributed diesel generatorsthat are operated by UW under the control of operators who (we hope) areresponsive to this function's advisory control signal. Having a human inthe control loop will affect the reliability of and confidence in thegenerators' responses, but having a human in the control loop in noother way affected the way that this function was designed. The humanoperator will introduce uncertainty in the likelihood that advisedcontrol actions will be heeded, and this uncertainty may be addressed infuture drafts of this function. This function should be useable for mostevent-driven distributed generators responses.

Block Input/Output Function Model:

Inputs:

Inputs for this function are identical to those defined in 2.4Residential Event-Driven Demand Response with several exceptions listedbelow. The baseline, inelastic generation is assumed to be the idlestate with no power being produced. Therefore, no generation pattern istracked by this function. If the generator is found to be scheduled forother objectives, the times at which the generators are to be activatedshould be tracked as a baseline and subtracted from predicted eventbehaviors.

-   -   P_(DG,L)—[kW]—Power that is expected to be generated at each        response level L. Many generator resources will offer one        response level and will be operated at a single power        level—perhaps the nameplate full power rating of the generator        or generators. Default: 0.0 kW (for each response level).    -   K_(DG)—[cost/energy: $/kWh]—unit cost of generated electrical        energy at which this distributed generation resource is able to        produce electrical energy.    -   K_(L)—[dimensionless count]    -   D_(min,L)—[time: minutes]    -   {N_(this year, L), N_(year, L), N_(this month, L), N_(month, L),        N_(this week, L), N_(week, L), N_(this day, L), N_(day, L),        N_(this hour, L), N_(hour, L)}—[dimensionless count].    -   {D_(this year, L), D_(year, L), D_(this month, L), D_(month, L),        D_(this week, L), D_(week, L), D_(this day, L), D_(day, L),        D_(this hour, L), D_(hour, L), D_(this event, L)}—[time        duration: minutes].    -   {TIS₀(t), TIS₀(t−5), . . . , TIS₀(t−5k)}—[$/kWh].    -   {TIS₀, TIS₁, . . . , TIS_(K-1)}—[$/kWh].    -   OPTIONAL INPUT: {Level, EventStartTime_(L),        EventDuration_(L)}—[Integer, UTC Time, UTC Duration].

Interim Calculation Products:

-   -   {DIST(TIS_(0,min)), DIST(TIS_(0,min)+Δ$), DIST(TIS_(0,b)), . . .        }—[dimensionless].    -   {N′_(this year, L), N′_(year, L), N′_(this month, L),        N′_(month, L), N′_(this week, L), N′_(week, L),        N′_(this day, L), N′_(day, L), N′_(this hour, L),        N′_(hour, L)}—[dimensionless count].    -   {D′_(this year, L), D′_(year, L), D′_(this month, L),        D′_(month, L), D′_(this week, L), D′_(week, L),        D′_(this day, L), D′_(day, L), D′_(this hour, L), D′_(hour, L),        D′_(this event, L)}—[time duration: minutes].

Outputs:

-   -   {ACS₀, ACS₁, . . . , ACS_(K-1)}—[dimensionless].    -   {ΔL₀, ΔL₁, . . . , ΔL_(K-1)}—[kW]. (In this case, the sign        convention should indicate that these are generation resources,        not electrical load.)

Pseudo Code Implementation: The algorithm by which infrequent events areto be determined from the incentive signal are identical to what wasdescribed elsewhere in this application.

-   -   5. Establish/update the statistical distribution of historical        TIS values.    -   6. Update incentive thresholds for this system of assets.    -   7. Determine demand-response event periods for this system of        assets by comparing the transactive control incentive signal        against updated incentive thresholds.    -   8. Update the advisory control signal time series for this        system of assets.    -   9. Predict change in average power that will result from        predicted demand-response control actions. A series of power        generation predicted for each IST interval should be calculated        corresponding to the set of advisory control signals that were        created in the previous step #4.        -   Where no effects of ramp periods or inelastic load patterns            should be modeled, then for each IST_(n) and each response            level L,            ΔL _(L)=0,            if ACS_(n)=0(no event) or TIS_(n) ≤K _(DG)  (1)    -   max(P _(DG,L)),    -   if both ACS_(n)≥ACS_(L) and TIS_(n)>K_(DG).    -   In simple terms, Equation 1 says that the distributed generators        should not operate and their elastic load is zero if either        there is no event for time interval n (ACS_(n)=0) or if the TIS        for the interval is less than the cost at which the generators        can generate (e.g., TIS_(n)≤K_(DG)). If however, the TIS exceeds        the cost at which the generators can generate and an event has        been determined to invoke one or more response levels (e.g.,        ACS_(n)≥ACS_(L)), then the amount of power predicted to become        generated is the maximum P_(DG,L) for the response levels L that        have been invoked.

Further Alternatives

-   -   1. Address effects of resource unavailability that may affect        the accuracy of predicted generation during events.    -   2. Address scheduled testing as (potentially) an inelastic        impact as generators are typically tested about an hour or so        each month, regardless of transactive control signals.    -   3. Address the uncertainty of elastic load series elements that        is introduced by human operators.    -   4. If in the future distributed generators are to be modeled        that have ramp-up and ramp-down periods that are comparable to,        or longer than, the update interval of the transactive control        and coordination system, then this function should be extended        accordingly. (The update interval being used in some embodiments        is 5 minutes. If a generator can generate full power within 30        seconds or so, the additional complexity of modeling the ramps        may not be worthwhile.) The effect of the ramp periods is that        the energy produced during the first event intervals, during        which the ramp-up occurs, will produce less energy than        P_(DG,L)×Δt for that interval. Energy may also be produced after        the final event interval while the generators ramp down. See        Appendix A for some calculations that anticipate these ramp-up        and ramp-down periods.

Subappendix A: Planning for Ramp-Up and Ramp-Down Periods

This appendix offers some insights about additional considerations,steps, and calculations that should be conducted if a distributedgeneration resource is found to use ramp-up and/or ramp-down periodsthat are comparable to, or longer than, the duration of the updateinterval.

One additional set of inputs is used to indicate whether ramp-up andramp-down periods are being modeled and their durations:

-   -   {ramp_(on), tr_(on), ramp_(off), tr_(off)}—[Boolean T/F,        minutes, Boolean T/F, minutes]—Input Boolean indicators that        indicate whether the distributed generation resource should be        ramped into service (ramp_(on)=“true”) or ramped out of service        (ramp_(off)=“true”). If either or both type of ramping is        necessary, this function will linearly ramp the predicted power        on over tr_(on) minutes and off over tr_(off) minutes. Default:        {“false”, 0.0, “false”, 0.0}.

The formulation uses additional sub-steps given the various possiblerelationships between tr_(on), tr_(off), and the IST_(n) times. Incertain embodiments, IST_(n*) is defined as the IST_(n) at which anevent and tr_(on) are initiated. In some embodiments, IST_(n**) isdefined as the IST_(n) that immediately follows the event. If it werenot for tr_(off), no power would be generated in the interval thatstarts at IST_(n**).

The approach will be to define generation power p_(n) at each timeIST_(n). Then, the average power may be determined from these points andknowledge of the ramp rates. FIG. 85 is a block diagram 9500 showing anexample model of ramp up and ramp down periods.

-   -   First, if        IST_(n)≤IST_(n*), or if IST_(n)≥IST_(n**) +tr _(off),  (A1)    -   then p_(n)=0.    -   However, if IST_(n) falls within the interval        IST_(n*)≤IST_(n)≤IST_(n**) +tr _(off),  (A2)    -   then assign p_(n) as shown in equation A3.

$\begin{matrix}{p_{n} = {\min( {\frac{( {{IST}_{n} - {IST}_{n^{*}}} ) \cdot P_{{DG},L}}{{{ramp}_{on} \cdot {tr}_{on}} + ɛ},P_{{DG},L},{( {1 - \frac{( {{IST}_{n} - {IST}_{n^{**}}} )}{{{ramp}_{on} \cdot {tr}_{on}} + ɛ}} ) \cdot P_{{DG},L}}} )}} & ({A3})\end{matrix}$

-   -   The small positive value epsilon has been used in the        denominators to avoid division by zero, which could otherwise        have occurred if either the Boolean operators ramp_(on) or        ramp_(off) were false (e.g., “0”) or if either of the ramp        durations tr_(on) or tr_(off) were zero.    -   Now that generation power has been determined at each time        IST_(n), the average power over each IST interval should be        estimated, where ramping may at times reduce the estimate.    -   For any interval prior to IST_(n*) or after IST_(n**)+tr_(off),        ΔL_(n)=0. No power is produced by the distributed generators        during these intervals.    -   For any interval IST_(n) that coincides with or follows IST_(n*)        and also starts before IST_(n**)+tr_(off), then

$\begin{matrix}\begin{matrix}{0,} & \begin{matrix}{p_{n} = 0} \\{p_{n + 1} = 0}\end{matrix} \\{{0.5*( {p_{n} + p_{n + 1}} )},} & \begin{matrix}{p_{n} < P_{{DG},L}} \\{p_{n + 1} < P_{{DG},L}}\end{matrix} \\{{{\Delta\; L_{n}} = \frac{\begin{matrix}{{p_{n + 1} \cdot ( {{IST}_{n + 1} - {IST}_{n} - {\frac{{tr}_{on}}{2} \cdot ( {1 - \frac{p_{n}}{p_{n + 1}}} )}} )} +} \\{p_{n} \cdot \frac{{tr}_{on}}{2} \cdot ( {1 - \frac{p_{n}}{p_{n + 1}}} )}\end{matrix}}{{IST}_{n + 1} - {IST}_{n}}},} & \begin{matrix}{p_{n} < P_{{DG},L}} \\{p_{n + 1} = P_{{DG},L}}\end{matrix} \\{\frac{\begin{matrix}{{p_{n} \cdot ( {{IST}_{n + 1} - {IST}_{n} - {\frac{{tr}_{off}}{2} \cdot ( {1 - \frac{p_{n + 1}}{p_{n}}} )}} )} +} \\{p_{n + 1} \cdot \frac{{tr}_{off}}{2} \cdot ( {1 - \frac{p_{n + 1}}{p_{n}}} )}\end{matrix}}{{IST}_{n + 1} - {IST}_{n}},} & \begin{matrix}{p_{n} = P_{{DG},L}} \\{p_{n + 1} < P_{{DG},L}}\end{matrix} \\{P_{{DG},L},} & \begin{matrix}{p_{n} = P_{{DG},L}} \\{p_{n + 1} = P_{{DG},L}}\end{matrix}\end{matrix} & ( {A\; 4} )\end{matrix}$

6.3.12 Incentive Function—Fossil Generation (Function 3.0)

Description:

This function provides the predict fossil generation and its costaggregated for each transmission zone.

The cost for generating fossil energy includes a fixed infrastructurecost and a variable production cost. The infrastructure cost will bebased on estimated amortized fossil generation plant infrastructureexpense; while the variable production cost is mainly based on fuelcost.

Fossil generators include the following types:

-   -   Nuclear    -   Coal    -   Geothermal    -   Natural Gas Combined Cycle

For simplicity, the infrastructure cost will be calculated for each ofthe above categories of generation based on the average capital costprovided in Subappendix B in (kaplan 2008).

-   -   Coal: 2519 $/kw    -   Nuclear: 3930 $/kw    -   Geothermal: 3170 $/kw    -   Natural Gas Combined Cycle: 1165 $/kw

The infrastructure cost of a fossil generating unit can thus beestimated if its capacity is known. This cost shall then be spread overthe lifetime T of the generating unit.

It is permissible for the implementer of this function to assume thatT=8760 (h/year)*40 (years)*0.9 (utilization factor)=315360 (hours) ifbetter estimates are unavailable for the lifetime of fossil generatingunit.

It is unlikely that any of the fossil units will surpass their statedlifetime in the short-time. However, after a generating unit exceeds itsplanned lifetime, a decision should be made. Thereafter, theinfrastructure cost may be (a) zeroed out, (b) replaced by ongoingmaintenance costs, or (c) continued as before as an ongoing replacementcost. This function should be revisited and refined when this situationwill be encountered.

The generating units available to meet system load are “dispatched” (puton-line) in order of lowest variable cost. This is referred to as the“economic dispatch” of a power system's plants. For a plant that usescombustible fuels (such as coal or natural gas) a key driver of variablecosts is the efficiency with which the plant converts fuel toelectricity, as measured by the plant's “heat rate.” This is the fuelinput in British Thermal Units (btus) used to produce one kilowatt-hourof electricity output. A lower heat rate equates with greater efficiencyand lower variable costs.

A Unit Commitment and Dispatch Engine is used to produce generation MW,that can meet BPA load forecast. Generation cost is calculated based onthe heat rate curves and fuel prices.

FIG. 86 is a block diagram 8600 of a block input/output function model,which is discussed below.

Inputs:

-   -   Predicted price of fuel, which may be either constant or a        dynamic time series, depending on the fuel.    -   Representative amortized infrastructure cost. (In some cases,        the infrastructure costs will be stated as functions of many        variables, including local costs of money, taxes, regulations,        etc.)    -   Planned generator schedule(s), such as Federal hydro schedules.    -   Constant heat rate curves of fossil generators.    -   BPA Load Forecast.    -   Historical BPA Netmom savecases, which are used to produce        generation and load profiles for any given hour of a day in a        week of a specific season.    -   Amortized Infrastructure cost C_(I,G)

Outputs:

-   -   Predicted average generated fossil power P_(TZ,IST) For a        Transmission Zone TZ for time series using the intervals of the        current IST time series.    -   Corresponding predicted energy costs of generated power in each        transmission zone C_(E,TZ,IST) using the intervals of the        current IST time series.    -   Predicted infrastructure cost in each transmission zone        C_(I,TZ,IST) time series using the intervals of the current IST        time series. (Infrastructure cost is not expected to be        especially dynamic, but it is specified as a time series for        consistency.)

Pseudo Code Implementation:

-   -   1. Process inputs from BPA;    -   2. Complement input data with the model data from historical        Netmom savecases and WECC heat rate curves;    -   3. Solve a multi-interval economic dispatch problem which        produces dispatch MW for each generator P_(G,t)    -   4. Calculate P_(TZ,IST) for transmission Zone TZ and interval        IST;

${P_{{TZ},{IST}} = {\sum\limits_{\underset{GisFossil}{G \in {TZ}}}\; P_{G,t}}},$where t is covers the majority portion of an IST interval

-   -   5. Compute the infrastructure cost C_(I,TZ,IST) corresponding to        each transmission zone TZ and each IST;

$C_{I,{TZ},{IST}} = {\sum\limits_{G \in {TZ}}( {{\sum\limits_{GisGas}{C_{I,{Gas}}*T_{IST}}} + {\sum\limits_{GisGeo}{C_{I,{Geo}}*T_{IST}}} + {\sum\limits_{GisCoal}{C_{I,{Coal}}*T_{IST}}} + {\sum\limits_{GisNuke}{C_{I,{Nuke}}*T_{IST}}}} )}$

-   -   6. Compute the energy product cost C_(E,TZ,IST) for each        transmission zone TZ and each IST;

${C_{{TZ},{IST}} = {\sum\limits_{\underset{GisFossil}{G \in {TZ}}}\;{{C_{G,t}/T_{t}}*T_{IST}}}},$where t is covers the majority portion of an IST interval

6.3.13 Load Function—Residential Time-of-Use Demand Response (Function3.4)

Description:

This function predicts the response from an automated residentialdemand-response system that will respond approximately daily to helpmitigate peak conditions that are evident in an incentive signal. Thepeak period will be based on response constraints and the TIS incentivesignal. (Note that this approach is more dynamic than typicaltime-of-use (TOU) demand response, in which daily peak and off-peakintervals remain immutable. The peak and off-peak periods recommended bythis function may be assigned differently each day according to eventsthat will have affected the predicted TIS incentive signals.) It may beapplied where programmable, communicating thermostats; smart appliances,demand-response switch units, or other assets are installed inresidences and where programs are designed to have these systems respondto daily peak periods.

In some cases, this function will be used by the asset systems IF-04(water heater control), IF-08 (thermostat load control), and LV-02(water heater demand-response units). (This document may be useful forthe determination of appropriate daily intervals, but a unique functionmay be used to predict the changes in elastic load from such a diverseand changing population of responsive assets.)

A first objective of this function is to establish the time periodsduring which the response level(s) should be called, based upon thenumbers and durations and preferred durations of these periods that arepermitted for each response level. The daily events and their durationsare positioned to best align with the levels of the TIS incentive signalthat has been predicted for the day.

The function should then predict the change in load that will resultfrom these events having been planned. This toolkit function addressessystems that control any combination of (1) residential space heating,(2) residential electric tank water heaters, or (3) smart appliances.Relatively simple models of populations of these devices are used topredict the changed load that they will consume as they respond to thesevarious peak periods.

Block Input/Output Function Model:

Inputs:

-   -   L—[dimensionless count]—number of response levels to be        prescribed for this asset system. For example, an asset system        that simply curtails its loads has one response level (e.g.,        “curtailed”), so L=1.    -   {Threshold₁, Threshold₂, . . . , Threshold_(I), . . . ,        Threshold_(L)}—[dimensionless fraction]—typical fraction of time        that each response level l should be active during a day. For        example, if a system with two response levels has its highest        level designed to respond during the two worst peak hours of a        day, then Threshold₂= 2/24=0.083. If the first level may include        an additional 2 hours in its peak period, then Threshold, =        4/24=0.17. In this example, the system would be in its normal,        non-responding condition for 1—Threshold₁—Threshold₂=0.75.        (Through this formulation, it will be assumed that the        thresholds are ordered in increasing order, from least to        greatest.) (Default={1/(L+1), 2/(L+1), . . . , I/(L+1), . . . ,        L/(L+1)})    -   {D_(min,week day,l), D_(min,weekend day,l),        D_(min,holiday,l)}—[time: minutes]—for each response level l,        minimum time duration for which an event level l should remain        in force for this day type after it has become initiated. (In        some cases, this can be stated in multiples of 5, 15, 60, or 360        minutes to align with the IST interval durations.) (Default={15        minutes, 15 minutes, 15 minutes})    -   {N_(min,week day,l), N_(min,weekend day,l),        N_(min,holiday,l)}—[dimension less count]—local static input        LI_29—limitations on the minimum number of TOU events that may        be called during the three major day types for each response        level l. (Default={0, 0, 0})    -   {N_(max,week day,l), N_(max,weekend day,l),        N_(max,holiday,l)}—[dimension less count]—local static input        LI_29—limitations on the maximum number of TOU events that may        be called during the three major day types for each response        level l. (Default={1, 0, 0})    -   {D_(max,week day,l), D_(max,weekend day,l), D_(max,holiday,l),        D_(max_event,l)—[time duration: minutes}—local static input        LI_30—maximum total event duration permitted per day type and        per event allowed for each event level l—constraints that have        been placed on the maximum total duration of events that may        endure during a day type or during an event. (In some cases,        this can be stated in multiples of 5, 15, 60, or 360 minutes to        align with the IST interval durations.) (Default={1440 minutes,        1440 minutes, 1440 minutes} (e.g., no limit))    -   {TIS₀(t), TIS₀(t−5), . . . , TIS₀(t−5k)}—[$/kWh]—recent history        of transactive incentive signals (TIS) by which the statistical        likelihood of various incentive levels will be assessed and        updated. The TIS₀ values from the TIS time series (e.g., the TIS        values that correspond to IST₀) from the last k five-minute        updates are used. (It should be allowed that a recursive method        be initiated, in which case historical TIS₀ data may not be        needed. If historical TIS₀ is not used, system responses should        initially be canceled or more conservatively applied until the        recursive method has learned a meaningful statistical        distribution of the TIS signals.)    -   {TIS₀, TIS₁, . . . , TIS_(K-1)}—[$/kWh]—current transactive        incentive signal TIS for future IST intervals.    -   P_(wh)(t)—[average kW]—typical electrical power consumption by        residential tank water heaters in this region as a function of        time of day. This function may be available as a function or as        a look-up table. See appendix material for an example.

Interim Calculation Products:

-   -   {DIST(TIS_(0,min)), DIST(TIS_(0,min)+Δ$), . . . ,        DIST(TIS_(0,b)), . . . }—[dimensionless]—distributions of        absolute TIS₀ values based on historic or monitored TIS        incentive signals.    -   {ϕ(TIS_(0,1)), ϕ(TIS_(0,2)), . . . , ϕ(TIS_(0,b)), . . . ,        ϕ(TIS_(0,B))}—[dimensionless fraction]—cumulative distribution        of historical TIS₀ values. (This will sometimes be abbreviated        as ϕ(b), where b is the bin that is lower bounded by TIS_(0,b).)

Outputs:

-   -   {ACP₀, ACP₁, . . . ACP_(K-1)}—[dimensionless]—asset control plan        for each future predicted interval. A standardized approach has        been specified by which planned response levels may be indicated        by integer values [−127,127].    -   {ΔL₀, ΔL₁, . . . , ΔL_(K-1)}—[kW]—average change in power caused        by the elastic behavior of this asset system for future        predicted intervals. The non-zero elements of this series        corresponding to non-zero elements of the asset control plan.        (Positive values are used here to refer to additional power that        is made available to the system by curtailed loads.)

Pseudo Code Implementation:

-   -   1. Establish/update the statistical distribution of historical        TIS₀ values. (This general process does not require that the        distribution of TIS incentive signals is a normal distribution.)        -   a. Using available historical information and the TIS time            series that becomes available to the transactive node at an            update interval, create a distribution of bins b that are            Δ$-wide for the available TIS₀ values. (Bins of size            Δ$=$0.001 are probably small enough for this function.) For            each available TIS₀,            If TIS_(0,b)≤TIS₀<TIS_(0,b)+Δ$,then set            DIST(TIS_(0,b))=DIST(TIS_(0,b))+1  (1)        -   TIS_(0,b)—[$/kWh]—lower boundary of distribution interval            DIST(TIS_(0,b)), bin b        -   TIS_(0,b)+Δ$—[$/kWh]—upper boundary of distribution interval            DIST(TIS_(0,b)), bin b        -   DIST(TIS_(0,b))—[dimensionless]—a tally count of the number            of times that TIS₀ have fallen into the interval bin b over            time. (Because the distribution will be normalized, it is            equally valid to sum the durations of the intervals,            resulting in a tally count of minutes.)    -   c. Using DIST(TIS₀), create a normalized cumulative distribution        ϕ(b) as shown in equation 2. The interpretation of ϕ(b) is the        fraction of TIS₀ that will be expected to fall in any of the        bins below bin b, inclusive. By subtracting ϕ(b) from 1.0, one        estimates the fraction of TIS₀ values that would be expected to        be greater than TIS_(0,b)+Δ$. Refer to Table 44 and FIG. 87,        which is a set 8700 of plots for DIST(TIS₀) and ϕ(b).

$\begin{matrix}{{\Phi(b)} = \frac{\sum\limits_{{bin}\mspace{11mu} 0}^{{bin}\mspace{11mu} b}\;{{DIST}( {TIS}_{0} )}}{\sum\limits_{{bin}\mspace{11mu} 0}^{{bin}\mspace{11mu} b}\;{{DIST}( {TIS}_{0} )}}} & (2)\end{matrix}$

-   -   -   ϕ(b)—[dimensionless fraction in the range [0,1]]—normalized            cumulative distribution of historical TIS₀ values in bins 0            through b, inclusive.        -   Bin 0—[$/kWh]—bin that possesses the smallest TIS₀ value            that can be found in DIST(TIS₀).        -   Bin B—[$/kWh]—bin that possesses the largest TIS₀ value that            can be found in DIST(TIS₀).

TABLE 44 Useful table for tracking the distribution of historical TIS₀values DIST(TIS₀) ϕ(b) Bin B . . . Bin b . . . Bin 1 Bin 0

-   -   -   A skilled implementer may choose to fit the normalized            cumulative distribution ϕ(b) column of Table 45 to a            monotonic function that could be used hereafter instead of            this lookup table.        -   DIST(TIS₀) and ϕ(b) may be updated whenever a new TIS₀            becomes available. (One may choose to update DIST(TIS₀) and            ϕ(b) at a time interval of his choice. Some seasonal            variation in the distribution should be anticipated.            Therefore, it is advised the distribution be established            representative of this month or this season.)

    -   2. Update incentive thresholds for this system of assets. This        step refers to the set {Threshold_(i)} to establish the typical        fraction of a day and TIS values for which a TOU event should be        active for a given response level l.        -   The value TIS_(0,b) in equation 3 is an acceptable threshold            TIS_(thresh,l) for future TIS values and response level l if            the condition of equation 3 is true. (One may interpolate to            find a better threshold value.) Determine an acceptable            threshold for each response level l using equation 3.            ϕ(b)≤1−Threshold_(l)<Φ(b+1)  (3)

    -   3. Calculate averaged TIS values from the thresholds and        statistical information. The raw threshold values are not as        useful as averaged TIS values for given response levels. For        each response level l, calculate the average of the TIS values        that are expected to fall greater than the level's threshold.

$\begin{matrix}{{\overset{\_}{TIS}}_{{thresh},l} \equiv \frac{\sum{( {{TIS}_{0,b}^{*} + {{0.5 \cdot}{\Delta\$}}} ) \cdot {{DIST}( {TIS}_{0,b}^{*} )}}}{\sum{{DIST}( {TIS}_{0,b}^{*} )}}} & (4)\end{matrix}$

-   -   -   TIS _(thresh,l)—[$/kWh]—average of TIS values expected to be            greater than TIS_(thresh,l).        -   TIS_(0,b)*+0.5·Δ$—[$/kWh]—the center of any DIST(TIS_(0,b))            bin b that holds values greater than or equal to            TIS_(thresh, l).        -   DIST(TIS_(0,b)*)—[dimensionless count]—the count of members            in DIST(TIS_(0,b)) bin b that hold values greater than or            equal to TIS_(thresh, l).

    -   4. Determine TOU event periods for this system of assets.        -   a. An initial calculation of candidate TOU periods is            completed to find periods of time during which the average            predicted TIS_(n) will be greater than or equal to TIS            _(thresh,l). In general, candidate TOU response periods for            response level l are the sets of IST intervals from IST_(n)            to IST_(n+m) (whole numbers m=0, 1, . . . ) that            simultaneously maximize the left-hand side of inequality 5            while also satisfying inequality 6.

$\begin{matrix}{{\frac{\sum\limits_{n^{*}}^{n^{*} + m^{*}}\;{{TIS}_{n} \cdot ( {{IST}_{n + 1} - {IST}_{n}} )}}{\sum\limits_{n^{*}}^{n^{*} + m^{*}}( {{IST}_{n + 1} - {IST}_{n}} )} \geq {\overset{\_}{TIS}}_{{thresh},l}},} & (5)\end{matrix}$

-   -   -   where            IST_(n*+m*+1)−IST_(n*) ≤D _(max,1)  (6)        -   n*—[dimensionless]—specific index n of the current IST_(n)            intervals that both maximizes the left-hand side of            inequality 5 and satisfies inequality 6 to define a TOU            period for response level l.        -   m*—[dimensionless index]—whole number index that combined            with n* maximizes the left-hand side of inequality 5 and            satisfies inequality 6 to define a TOU period for response            level l.        -   IST_(n*+m*+1)—[time in UTC]—ending time of the newly defined            TOU period.        -   IST_(n*)—[time in UTC]—beginning time of the newly defined            TOU period.        -   D_(max,l)—[time: minutes]—relevant maximum period duration            or durations for this day or event selected from the defined            input set {D_(max,weekday,l), D_(max,weekend day,l),            D_(max,holiday,l), D_(max event,l)}.        -   If more than one response level is being used (e.g., L>1),            then this step will likely have defined nested response            periods where the periods of response level 1 are nested            within periods of response level 2, and so on. Normally, the            hierarchy or priority of these nested response periods will            be trivial, such that the response periods with smaller            response level l trump those of greater l.        -   There are L+1 total levels. The remaining level L+1 will            most often, but not necessarily, be assigned to normal            operation, unmodified by the TIS.        -   Because the IST intervals gradually change from granular to            coarse into the future, the function might see response            levels over or under prescribed far into the future when            coarse 6-hour or daylong IST intervals have been specified.            These conditions should disappear as representations become            finer and may be mitigated, to a degree, by the input            assignments of maximum allowed TOU period durations.

    -   b. Special case: The number of defined events is more than the        maximum number allowed for a given day. If for any response        level l and day type there have been defined a number of TOU        periods and their respective n* indices within a day that        exceeds the relevant limit from the defined input set        {N_(max,week day,l), N_(max,weekend day,l), N_(max,holiday,l)},        then those periods within the day having the least (lesser) of        the magnitudes on the left-hand side of inequality 5 should be        discarded.

    -   c. Special case: The number of defined events is less than the        minimum number allowed for a given day and its day type. If for        any response level l and day type there has been defined a        number of TOU periods and their respective n* indices within the        day fewer than the minimum number of response periods allowed by        the input set {N_(min,week day,l), N_(min,weekend day,l),        N_(min,holiday,l)}, then inequality 6 and inequality 7 should be        relaxed somewhat as shown in inequalities 7 and 8. The corrected        indices n* and m* will yield an acceptable number of event        periods for this response level l and day type. The corrected        indices n* and m* are those that solve inequalities 7 for the        smallest positive real number δ for which the minimum allowed        TOU period duration of inequality 8 is achieved.

$\begin{matrix}{{\frac{\sum\limits_{n^{*}}^{n^{*} + m^{*}}\;{{TIS}_{n} \cdot ( {{IST}_{n + 1} - {IST}_{n}} )}}{\sum\limits_{n^{*}}^{n^{*} + m^{*}}( {{IST}_{n + 1} - {IST}_{n}} )} \geq {{\overset{\_}{TIS}}_{{thresh},l} - \delta}},} & (7)\end{matrix}$

-   -   -   where            D _(min,1)≤IST_(n*+m*+1)−IST_(n*) ≤D _(max,1)  (8)        -   δ—[$/kWh]—smallest positive real value for which            satisfactory indices n* and m* exist.        -   D_(min,l)—[time: minutes]—minimum TOU period duration            allowed for this day type and response level as selected            from defined inputs {D_(min,l), D_(min,2), . . . ,            D_(min,l), . . . , D_(min,L)}.        -   One may revisit inequalities 7 and 8 until the minimum            allowed numbers of events have been defined.

    -   5. Specify the prioritization of response levels. Because the        TOU periods will have been assigned nested one inside another,        the designer should specify the prioritization or hierarchy of        the assigned response levels.        -   a. Example 1: Curtailment using one response level. One can            start with one of the simplest cases. Suppose that a            controlled electrical load will be curtailed during response            level 1 and behave normally otherwise. The prioritization of            the response levels here is trivial as shown in Table 46.            (The advisory control signal column “ACS” in this table will            be discussed in the next section.)

TABLE 45 Response-Level Prioritization for Curtailment Example ResponseLevels Priority Assigned to IST_(n) Assignment Action/Outcome ACS 1 1Curtailed system 127 operation none none Normal operation 0

-   -   -   b. Example 2: Five-level TOU battery system. As the number            of response levels and complexity of the controlled asset            system increases, the challenge of prioritizing the response            levels increases, too. Refer to Table 47, which defines the            priority of assignments to be made for a battery system that            has four response levels available to it. (Those who are            familiar with battery storage will correctly recognize that            a battery system will have additional constraints that may            be managed either implicitly or explicitly.) This example            has the additional complexity from a storage system that can            either increase the available power (ACS>0) or decrease the            available power (ACS<0) at its transactive node.

TABLE 46 Response-Level Prioritization for a Battery System with FiveAvailable Response Levels Response Levels Priority Assigned to IST_(n)Assignment Action/Outcome ACS 1, 2, 3, and 4 1 Maximum Charge Bias −127Strategy 2, 3 and 4 2 Moderate Charge Bias −64 Strategy 3 and 4 3Inactive Dead Zone 0 4 4 Moderate Discharge Bias 64 Strategy noneremaining level Maximum Discharge Bias 127 Strategy

-   -   6. Update the advisory control signal time series for this        system of assets. Advisory control signals are discussed        elsewhere in this application. In short, an advisory control        signal should be stated for an IST interval n and will be        non-zero for any interval during which a response other than        normal operation is planned. Refer to Table 48 that lists the        advisory control signals candidates that will typically be sent        for curtailable loads and distributed generation according to        the numbers of response levels available from these assets.

TABLE 47 Recommended assignable advisory control signals for curtailableload and “dispatchable” distributed generation Number of AdvisoryControl Response Levels Signals ACS_(n) 1 0 (normal) 127 (curtailed) 2 0(normal) 64 (level 1) 127 (level 2) 3 0 (normal) 42 (level 1) 84 (level2) 127 (level 3) 4 Etc.

-   -   7. Model and predict the change in elastic load that should be        expected from the controlled, responsive asset system. The        output from this toolkit function into the overall algorithmic        responsibilities of the transactive node (e.g., the “toolkit        framework”) expects to receive a series of predicted changes in        electrical load ΔL_(n) for each IST interval n. The process or        model by which this prediction is made is somewhat unique for        the given asset system and its capabilities. The prediction will        be affected by the planned response level (as indicated by the        corresponding advisory control signal) and other information        used by the model as it makes its prediction.        -   The following models are expected to be relevant to this            toolkit function and are included by reference:            -   a. Electric tank water heater model. Toolkit function                2.4_Residential Event-Driven Demand Response includes                details about trends for electricity consumption by                residential electric tank water heaters in the                Northwest. There, one will find a lookup file that may                be used to predict the average power that may be                curtailed by time of day for week days and weekend days.                The use of the lookup table should be identical for this                function as for the referenced function. Please refer to            -   b. Thermostatic space conditioning dynamic model.                Toolkit function 2.4_Residential Event-Driven Demand                Response also documents a dynamic state model that may                be used to predict the change in energy consumed by                buildings based on predicted outdoor temperature, solar                insolation, and parameters through which numbers and                sizes of buildings, insulation levels, and other                building qualities may be represented. The thermostat                model tracks a representative building interior                temperature that may, in turn, be affected by modeled                occupancy set points and by demand-response levels.

Further Alternatives:

There might exist a preferable way to organize toolkit load functionsaccording to (1) the way events are related to the TIS time series and(2) the asset system models. The present organization, in which thesetwo elements have been combined into each toolkit function, isinefficient and uses multiple cross references and duplications.

The means by which TOU periods are specified from the TIS proved, whileconceptually easy, to be relatively difficult to describe and specify.This function should be further refined as implementers learn ways tomathematically represent the process that has been described herein.

Subappendix A—Revised High-Level Pseudo Code

While the pseudo code in the function's specification remains largelycorrect, the interpretation of selecting the event interval having the“maximum average TIS” was open to interpretation. If strictly followed,the algorithm would select only the events having minimum duration. Thefollowing general strategy proved useful.

The following general steps were

-   -   1. Parse future intervals into their local (not UTC) days. (This        cannot be strictly performed because long intervals, which were        aligned with UTC time, do not correctly align with midnight        local time.)    -   2. Review the history of the first day using TIS_0 values within        the day. Use only the last of the historical relaxation        calculations within any 5-minute update interval and discard        other relaxation intervals that were overridden. Update the        numbers of time-of-use events, ongoing event duration, and total        event duration for the day.    -   3. Calculate average TIS for permutations of contiguous        intervals within the first and each remaining day that have an        allowed duration.    -   4. Select the permutation that gives the maximum average TIS.    -   5. Tentatively state that the new selected interval(s), plus any        prior-approved intervals, are part of the day's event(s).    -   6. Test the set of tentatively engaged intervals. If        -   a. Total event duration is not more than the maximum allowed            for day,        -   b. AND the number of events does not exceed the number            allowed for the day,        -   c. AND (the event duration is less than or equal to the            minimum OR the selected intervals' average TIS value is            greater than or equal to a threshold),        -   d. AND (the number of events fewer than or equal to the            minimum count OR the selected intervals' average TIS value            is greater than or equal to a threshold),        -   Then include tentative intervals among prior-selected            intervals.    -   7. Select the permutation that gives the next maximum average        TIS and go to repeat step 4.

6.3.14 Load Function—Time-of-Use Distribution System Voltage Control(Function 3.5)

Description:

This toolkit load function is similar to Toolkit Function 2.2Event-Driven Distribution System Voltage Control, except voltage iscontrolled in this function according to daily on- and off-peaktime-of-use periods. (“Time-of-use,” as used here is more dynamic thantime-of-use demand response is currently practiced. This functiondynamically determines appropriate peak and off-peak periods based onthe condition of a relatively dynamic incentive signal.) This toolkitfunction is applicable where voltage is to be controlled at two or morelevels according to the value of the TIS and constraints input byutilities and where responses of the asset have been designed to occuraccording to daily on- and off-peak periods.

During the strategic design of toolkit load functions, it has beenobserved that the functions that share time-of-use objectives are verysimilar, and functions that control the same type of asset system arealso similar. This present function makes efficient use of thisobservation and incorporates similar toolkit load function objectivesand text by reference.

Block Input/Output Function Model:

Inputs:

Include by reference the list of inputs in Toolkit Load Function 3.4Residential Time-of-Use Demand Response.

-   -   CVRf—[dimensionless fraction]—ratio of relative percentage        change in energy that will accompany a relative percentage        change in voltage for a circuit or set of circuits. (Default        value=0.7) (The CRV factor depends on circuit type and circuit        characteristics, but it will often be unknown. A typical default        value has been provided based on readily available reports, but        a utility may use different and better numbers if they possess        better information about their circuits.) In principle, this        factor could be different for each feeder, but this formulation        will assume that only one factor has been defined for the        region. If multiple factors will be employed, the extension of        this toolkit function will be straightforward.    -   {ΔV₁, ΔV₂, . . . , ΔV_(I), . . . ΔV_(L)}—[dimensionless        fraction]—fractional change in nominal system voltage enacted        under each response level l. These changes in voltage will        normally be negative, meaning the voltage will have been        decreased below its nominal set point.    -   {P₀, P₁, . . . , P_(n), . . . , P_(N−1)}—[kW]—predicted average        nominal load during each IST_(n) interval for the entire region        in which the distribution voltage is being controlled. The        prediction is for the nominal condition No_(minal), which may        be, but is not necessarily, when ΔV is equal to zero. (What is        desirable here is to capture the percentage changes in voltage        that will occur during various transactive-control response        levels. It does not especially matter whether the nominal        voltage is already lowered at all times (“nominal”) for        conservation purposes.) It will be presumed that Toolkit Load        Function 1.0 Bulk Inelastic Load has been employed at this        transactive node to predict the load for this region that is        affected by distribution load control. Electrical load is        normally formulated with a negative sign.

Interim Calculation Products:

Same.

Outputs:

Same.

Pseudo Code Implementation:

-   -   1. Establish/update the statistical distribution of historical        TIS₀ values.    -   2. Update incentive thresholds for this system of assets.    -   3. Calculate averaged TIS values from the thresholds and        statistical information.    -   4. Determine TOU event periods for this system of assets.    -   5. Specify the prioritization of response levels.    -   6. Update the advisory control signal time series for this        system of assets.    -   7. Model and predict the change in elastic load that should be        expected from the controlled, responsive asset system. The        output from this toolkit function into the overall algorithmic        responsibilities of the transactive node (e.g., the “toolkit        framework”) expects to receive a series of predicted changes in        electrical load ΔL_(n) for each IST interval n.        -   The predicted change in electrical load ΔL_(n) for this            toolkit load function is strongly influenced by the            conservation voltage reduction factor CVRf. This factor is            usually known imprecisely, so one may rely upon a default            value.        -   The change in elastic load is zero until a TOU event occurs.            During IST intervals n*, during which a TOU response period            is planned for level l, the change in elastic load is            predicted by equation 1. (CRVf is normally calculated from            energy savings. Some might debate the way it has been            applied in equation 1 to individual intervals. The factor is            not perfectly applicable to short intervals, where immediate            changes in load might not be representative of long-term            changes in energy consumption. For this reason, the            prediction from equation 1 might be somewhat conservatively            made for very short intervals. The effect is probably            small.)            ΔL _(n*,l)=CVRf·ΔV _(l) ·P _(n*)  (1)            -   n*—[dimensionless index]—index of those IST_(n)                intervals during which a TOU period is active at                response level l.            -   ΔL_(n*,l)—[kW]—change in elastic load that has been                induced by operating at response level l during IST                interval n. ΔL_(n,l) is equal to zero for n≠n*. The sign                of ΔL_(n*,l) should be positive where voltage has been                reduced, thus reducing energy consumption and making                more energy available to the region.            -   ΔV_(l)—[dimensionless fraction]—fractional change in                system voltage enacted by the utility under response                level l.            -   P_(n*)[kW]—predicted average power that would have been                consumed during this IST interval n* if no TOU event                were planned in this region of the distribution circuit.

6.3.15 Load Function—Time-of-Use Distribution System Voltage Controlwith Load Shedding Effect (Function 3.51)

Description:

This toolkit load function is based on Load Toolkit Function 3.5Time-of-Use Distribution System Voltage Control, but includes the effectof concurrent shedding of customer loads (e.g. water heaters,thermostatic space conditioning, etc.) that use augmented conservationregulation. For example, this function should be used byMilton-Freewater's test case MF-02-1.2, in which time-of-use voltagereduction both earns conservation from circuit loads and triggers GridFriendly™ water heaters to turn off.

This function relies on the approach that was formulated in toolkitfunctions 3.4 Residential Time-of-Use Demand Response and 3.5Time-of-Use Distribution System Voltage Control.

Block Input/Output Function Model:

Inputs:

-   -   Include by reference the list of inputs in Load Toolkit Function        3.4 Residential Time-of-Use Demand Response.    -   CVRf—[dimensionless number].    -   {ΔV₁, ΔV₂, . . . , ΔV_(l), . . . , ΔV_(L)}—[dimensionless        number].    -   {P₀, P₁, . . . , P_(n), . . . , P_(N−1)}—[kW].

Interim Calculation Products:

-   -   Same.

Outputs:

-   -   Same.

Pseudo Code Implementation:

-   -   1. Establish/update the statistical distribution of historical        TIS₀ values.    -   2. Update incentive thresholds for this system of assets.    -   3. Calculate averaged TIS values from the thresholds and        statistical information.    -   4. Determine TOU event periods for this system of assets.    -   5. Specify the prioritization of response levels.    -   6. Update the advisory control signal time series for this        Time-of-Use Distribution System Voltage Control asset system.    -   7. Model and predict the change in elastic load that should be        expected from the Time-of-Use Distribution System Voltage        Control asset system. The overall algorithmic framework of the        transactive node (the “toolkit framework”) expects to receive a        series of predicted changes in electrical load ΔL_(n) for each        IST interval n.        -   The predicted change in electrical load ΔL_(n) for this            toolkit load function is strongly influenced by the            conservation voltage reduction factor CVRf, which in turn is            dependent on the electrical characteristics of the system            and varies with the system load. This factor is usually            known imprecisely, so one rely upon a default value.        -   The change in elastic load is zero until a TOU event occurs.            During IST intervals n*, during which a TOU response period            is planned for level l, the change in elastic load is            predicted by equation 1. (CRVf is normally calculated from            energy savings. Some might debate the way it has been            applied in equation 1 to individual intervals. The factor is            not perfectly applicable to short intervals, where immediate            changes in load might not be representative of long-term            changes in energy consumption. For this reason, the            prediction from equation 1 might be somewhat conservatively            made for very short intervals. The effect is probably            small.) (Subtracting ΔL_(load_n*) from P_(n*) changes the            load-dependent CVRf factor. Given the limitation of the            project participants to precisely determine CVRf, the            interdependency between P_(n) and CVRf is disregarded in            equation 1.)            ΔL _(n*,l)=CVRf·ΔV _(l)·(P _(n*) −ΔL _(load_n*))+ΔL            _(load_n*)  (1)            -   n*—[dimensionless index]—index of those IST_(n)                intervals during which a TOU period is active at                response level l.            -   ΔL_(n*,l)—[kW]—change in elastic load that has been                induced by reducing voltage at response level l during                IST interval n. ΔL_(n,l) is equal to zero for n≠n*. The                sign of ΔL_(n*,l) should be positive where voltage has                been reduced, thus reducing energy consumption and                making more energy available to the region.            -   ΔV_(l)—[dimensionless fraction]—fractional change in                system voltage enacted by the utility under response                level l.            -   P_(n*)—[kW]—predicted average power that would have been                consumed during this IST interval n* if no voltage                control or load shedding event were planned in this                region of the distribution circuit.            -   ΔL_(load_n*)—[kW]—average change in power caused by the                elastic behavior of customer loads in the region, where                TOU voltage control is being applied, during IST                interval n. ΔL_(load_n) is equal to zero for n≠n*. The                sign of ΔL_(load_n*) should be positive where voltage                has been reduced, and is computed as shown elsewhere in                this application.

Example

-   -   CVRf=1 on average for a given utility feeder.    -   L=1 and ΔV₁=3%=0.03.    -   IST₀=midnight; TOU event scheduled to start at 7 a.m. (IST₃₃)        and end at 10 a.m. (IST₃₆).    -   P_(n) is known as shown in FIG. 1 below. P₃₃=9118 kW, P₃4=9260        kW, and P₃₅=8812 kW.    -   During TOU event, 1000 water heaters will be triggered to turn        off. For example, ΔL_(load_33)=1000×mean(0.817, 0.785, 0.738,        0.713) kW=763 kW, ΔL_(load_34)=1000×mean(0.716, 0.687, 0.672,        0.636) kW=678 kW, and ΔL_(load_35)=1000×mean(0.615, 0.584,        0.563, 0.518) kW=570 kW.    -   Applying equation (1) above, ΔL₃₃=1×0.03×(9118−763)+763 kW=1014        kW, ΔL₃4=1×0.03×(9260-678)+678 kW=935 kW, and        ΔL₃₅=1×0.03×(8812−570)+570 kW=817 kW.

FIG. 88 is an illustration 8800 of TOU voltage control concurrent withshedding water heaters.

6.3.16 Load Function—Non-Renewal Generation Time-of-Use Demand Response(Function 3.7)

Description:

This function predicts the response from a non-renewable distributedgenerator demand-response system that will respond approximately dailyto help mitigate peak conditions that are evident in an incentivesignal. The peak period will be based on response constraints and theTIS incentive signal. (Note that this approach is more dynamic thantypical time-of-use (TOU) demand response, in which daily peak andoff-peak intervals remain immutable. The peak and off-peak periodsrecommended by this function may be assigned differently each dayaccording to events that will have affected the predicted TIS incentivesignals.) This function relies on the approach that was formulated intoolkit function 3.4 Residential Time-of-Use Demand Response.

A first objective of this function is to establish the time periodsduring which the response level(s) should occur, based upon the numbersand durations and preferred durations of these periods that arepermitted for each response level. The daily events and their durationsare positioned to best align with the levels of the TIS incentive signalthat has been predicted for the day.

The function should then predict the change in load that will resultfrom these events. Specifically, what additional energy will begenerated at each prescribed response level.

Block Input/Output Function Model:

Inputs:

-   -   m—[power per time: kW/minute]—maximum allowed linear rate of        change in generated power. This value may at times limit the        rate at which control changes are permitted and may thereby        modify the generation power predictions. This is a strictly        positive number. Default: 100 MW/minute (e.g., an essentially        infinite rate of change is allowed by default).    -   L—[dimensionless count]—Default: 1.    -   {Threshold₁, Threshold₂, . . . , Threshold_(l), . . . ,        Threshold_(L)}—[dimensionless fraction]. (Default={1/(L+1),        2/(L+1), . . . , l/(L+1), . . . , L/(L+1)})    -   {D_(min,week day,l), D_(min,weekend day,l),        D_(min,holiday,l)}—[time: minutes].    -   {N_(min,week day,l), N_(min,weekend day,l),        N_(min,holiday,l)}—[dimensionless count].    -   {N_(max,week day,l), N_(max,weekend day,l),        N_(max,holiday,l)}—[dimensionless count].    -   {D_(max,week day,l), D_(max,weekend day,l), D_(max,holiday,l),        D_(max event,l)}—[time duration: minutes].    -   {TIS₀(t), TIS₀(t−5), . . . , TIS₀(t−5k)}—[$/kWh].    -   {TIS₀, TIS₁, . . . , TIS_(K-1)}—[$/kWh].    -   {P_(weekday)(0), P_(weekday)(1), . . . , P_(weekday)(h),        P_(weekday)(23)}—[power: kW]—typical baseline power that is        generated during UTC hour h of a weekday day type by this        distributed generation resource. Additional inputs may be used        in implementations that anticipate more day types other than        weekdays and weekend days. Default: {0, 0, . . . }.    -   {P_(weekend)(0), P_(weekend)(1), . . . , P_(weekend)(h),        P_(weekend)(23)}—[kW]—typical baseline power that is generated        during hour h of a weekend day by this distributed generation        resource. Default: {0, 0, . . . }.    -   {ΔP₁, ΔP₂, . . . , ΔP_(L)}—[power: kW]—Change in generation that        may be anticipated at each of the L response levels, with        respect to inelastic load. It is presumed that the opportunity        to generate at each level may be assigned as a constant        regardless of hour of day. This list may be updated seasonally        for cogeneration plants that may be affected by changes in        seasonal thermal heating loads.

Interim Calculation Products:

-   -   {DIST(TIS_(0,min)), DIST(TIS_(0,min)+Δ$), . . . ,        DIST(TIS_(0,b)), . . . }—[dimensionless].    -   {ϕ(TIS_(0,1)), ϕ(TIS_(0,2)), . . . , ϕ(TIS_(0,b)), . . . ,        ϕ(TIS_(0,B))}—[dimensionless fraction].

Outputs:

-   -   {L₀, L₁, . . . , L_(K-1)}—[kW]—inelastic load (generation) from        these generators. The generated power that is predicted to occur        at response level 0 (e.g., no response) during each of the K IST        intervals. (This baseline series will normally become reported        as inelastic load. Caution should be used that its impact is not        double-counted. Also, it should be assumed that none of the        transitions during typical operations will be permitted to        exceed the allowed rate of change.)    -   {ACS₀, ACS₁, . . . , ACS_(K-1)}—[dimensionless].    -   {ΔL₀, ΔL₁, . . . , ΔL_(K-1)}—[kW].

Pseudo Code Implementation:

-   -   1. Establish/update the statistical distribution of historical        TIS₀ values.    -   2. Update incentive thresholds for this system of assets.    -   3. Calculate averaged TIS values from the thresholds and        statistical information.    -   4. Determine TOU event periods for this system of assets.    -   5. Specify the prioritization of response levels.    -   6. Update the advisory control signal time series for this        system of assets.    -   7. Model and predict the inelastic load and the change in        elastic load that should be expected from the controlled,        responsive asset system.        -   a. Inelastic Load—Case where no limit is imposed on rate of            change (essentially infinite rate of change)            -   The inelastic load (generation) from the distributed                generator assets is the generated power that is expected                to occur if the generators were unaffected by                transactive control and operated normally, not in any                response level. If there is no limit imposed on the rate                that generation can occur, then the inelastic load is                predicted simply from the hourly generation profiles for                each day type, which are inputs to this toolkit                function. Two day types—weekday and weekend (including                holidays)—are defined, but the rule of equation 1 should                be formulated for each day type that is being modeled                for the given IST interval k.

$\begin{matrix}{L_{k} = \{ \begin{matrix}{{{P_{weekday}(h)}\mspace{14mu}{or}\mspace{14mu}{P_{weekend}(h)}},} & {{{if}\mspace{14mu}\lbrack {{IST}_{k},{IST}_{k + 1}} )} \subseteq \lbrack {{h:00},{{h + 1}:00}} )} \\{{{mean}\mspace{11mu}( {{P_{weekday}( h^{*} )},{P_{weekend}( h^{*} )}} )},} & {{{if}\mspace{14mu}\lbrack {{h^{*}:00},{{h^{*} + 1}:00}} )} \Subset \lbrack {{IST}_{k},{IST}_{k + 1}} )}\end{matrix} } & (1)\end{matrix}$

-   -   -   -   -   L_(k)—[average power: kW]—inelastic load                    (generation) during interval [IST_(k), IST_(k+1)).                    Default; 0.00 kW.                -   P_(weekday)(h)—[average power: kW]—typical weekday                    power generated by this resource during hour h.                -   h—[hour]—UTC clock hour at which an hour-long                    interval starts. The notation h* has been used to                    refer to a set of hours that initiate hour-long                    intervals that are a subset of an IST interval. The                    hour-long interval starting at h has been shown as                    [h:00,h+1:00).

        -   b. Elastic Load—Case where no limit is imposed on rate of            change            -   Elastic load is the predicted change in generation when                compared to the unaffected inelastic load prediction. In                the case where no limit has been imposed on the rate of                change in generation, the magnitudes of these changes                are found by simply allocating the ΔP_(l) input values                to the IST intervals having the corresponding response                level l as shown in equation 2.

$\begin{matrix}{{\Delta\; L_{k}} = \{ \begin{matrix}{{\Delta\; P_{l}},} & {{{if}\mspace{14mu}{ACS}_{k}} = {ACS}_{l}} \\{0,} & {otherwise}\end{matrix} } & (2)\end{matrix}$

-   -   -   -   ΔL_(k)—[average power: kW]—change in power                (generation)—the elastic load expected during the                interval that begins at IST_(k).            -   ΔP_(l)—[average power: kW]—the change in power                (generation) expected at times that the modeled                distributed generator resource is in its response level                l.            -   ACS_(k)—Advisory control signal that has been assigned                by this function during the interval that starts at                IST_(k).            -   ACS_(l)—Advisory control signal that has been assigned                if the modeled generator is to be at its response level                l.

        -   c. Inelastic and Elastic Load where a limit has been imposed            on the rate of change of generated power. In the case where            the rate of change of generated electric power is to be            constrained, this function should keep track of the power            generated at the beginning of each interval. This attainable            power for the interval boundaries are at times modified by            the allowed rate of change m as shown in equation 3 and            FIG. 1. These are additional steps to be taken after            equations 1 and 2. The power at IST_(k+1) is predicted from            the power at IST_(k) and the allowed rate of change in            generated power m. (This formulation and equation 3 have a            minor challenge for the determination of p₀, the power at            time IST₀. This value should either be determined by current            measurement, or it should be inferred from the prior            calculation that was conducted during a prior update            interval. This implies a desire for the parameter to be            stored from one iteration to the next (e.g., the value p₁            from five minutes ago is now the best estimate of p₀; each            of these values refer to the same IST time value).)

$\begin{matrix}{p_{k + 1} = \{ \begin{matrix}{{\min( {{p_{k} + {m \cdot ( {{IST}_{k + 1} - {IST}_{k}} )}},{L_{k} + {\Delta\; L_{k}^{\prime}}}} )},} & {{{{if}\mspace{14mu} L_{k}} + {\Delta\; L_{k}^{\prime}}} \geq p_{k}} \\{{\max( {{p_{k} - {m \cdot ( {{IST}_{k + 1} - {IST}_{k}} )}},{L_{k} + {\Delta\; L_{k}^{\prime}}}} )},} & {{{{if}\mspace{14mu} L_{k}} + {\Delta\; L_{k}^{\prime}}} < p_{k}}\end{matrix} } & (3)\end{matrix}$

-   -   -   -   p_(k)—[power: kW]—generated power at beginning of                interval IST_(k).            -   m—[power per time: kW/minute]—allowed rate of change in                generated power. This formulation assumes the same                restrictions apply for both ramping up and down.            -   L_(k)—[average interval power: kW]—inelastic load during                interval IST_(k) as was calculated in equation 1 above.            -   ΔL′_(k)—[average interval power: kW]—elastic load during                interval IST_(k) as was first calculated in equation 2                above.

FIG. 89 is a series 8900 of plots that show possible scenarios forchanges in generation during one interval. The average elastic loadΔL_(k) for the interval that starts at IST_(k) is then recalculatedusing the powers p_(k) and p_(k+1) at the intervals boundaries as shownin equation 4.

$\begin{matrix}{{\Delta\; L_{k}} = \{ \begin{matrix}{{\frac{\begin{matrix}{{p_{k + 1} \cdot ( {{IST}_{k + 1} - {IST}_{k} - \frac{p_{k + 1} - p_{k}}{m}} )} +} \\\frac{p_{k + 1}^{2} - p_{k}^{2}}{2 \cdot m}\end{matrix}}{{IST}_{k + 1} - {IST}_{k}} - L_{k}},} & {\mspace{14mu}\begin{matrix}{{{if}\mspace{14mu} p_{k + 1}} \geq {p_{k}\mspace{14mu}{and}}} \\{p_{k + 1} = {L_{k} + {\Delta\; L_{k}^{\prime}}}}\end{matrix}} \\{{\frac{\begin{matrix}{{p_{k + 1} \cdot ( {{IST}_{k + 1} - {IST}_{k} - \frac{p_{k} - p_{k + 1}}{m}} )} +} \\\frac{p_{k}^{2} - p_{k + 1}^{2}}{2 \cdot m}\end{matrix}}{{IST}_{k + 1} - {IST}_{k}} - L_{k}},} & \begin{matrix}{{{if}\mspace{14mu} p_{k}} \geq {p_{k}\mspace{14mu}{and}}} \\{p_{k + 1} = {L_{k} + {\Delta\; L_{k}^{\prime}}}}\end{matrix} \\{{\frac{p_{k} + p_{k + 1}}{2} - L_{k}},} & {otherwise}\end{matrix} } & (4)\end{matrix}$

Steps 2-7 (and perhaps 1, too) should be iterated each update interval.

Further Alternatives:

-   -   1. This function has its event times invoked by relative TIS        values. For some future DG systems, there costs of operation        will be more completely modeled, and the boundaries between        time-of-use events will be based on absolute thresholds of the        TIS signal. Additional operational inputs like actual steam load        and price of fuel would be used by these future improvements to        this function.

6.3.17 Incentive Function—General Infrastructure Cost (Function 4.0)

Description:

Where transactive control is applied at the device level, each devicewould have the opportunity to inject the impact of hardware costs (e.g.,its infrastructure costs). However, where transactive control has beenapplied to large aggregate regions, the owner of the large aggregatetransactive node may be unable or unwilling to accurately represent theimpact of infrastructure costs on the delivered cost of energy. Thepurpose of this function, therefore, is to represent the influence ofbulk infrastructure costs on the delivered cost of electrical energywhere it might be impracticable to track the costs of individualinfrastructure components.

The effect of this function should be to apply an offset to thecalculation of the delivered cost of energy (e.g., the transactiveincentive signal (TIS)). It is assumed by this function that thedifference between the sum of existing resource costs and incentives,which are otherwise already represented in the TIS, and an accepteddelivered cost of energy is attributable to infrastructure costs. (Thisassumption may be somewhat imperfect due to profit, labor costs, taxesand other impacts.)

This toolkit function may be applied at any of the transactive nodes,but it is desirable that transmission zone transactive nodes use thisfunction to represent the bulk impact of generation and transmissioninfrastructure costs that might not have otherwise been included.

Negative C_(I) parameter outputs are to be disallowed in order to haltmost occurrences of negative calculated TIS in the system.

Block Input/Output Function Model:

Inputs:

TIS₀(n)—[cost/energy: default: $/kWh]—(series of real floating)—timeseries of the transactive control signal (TIS) at interval start timezero (IST₀) at each of a series of update intervals n. (The updateinterval may be 5 minutes. In certain embodiments, a TIS is calculatedand transmitted at least once by this transactive node at each updateinterval. Of the interval values within each TIS, only the first, TIS₀,that refers to the nearest 5-minute interval is to be used by thisfunction.)

TIS_(avg)—[cost/energy: default: $/kWh]—(real floating scalar)—typical,or long-term average, value of TIS₀(n). This value should be observedfrom or analyzed from calculated TIS values at this transactive node.This value is used only during initialization of the infrastructure costparameter C_(I). The default value $0.04/kWh may be used, but doing somay introduce an initialization error that can take months to fullyeliminate.

TIS_(target)—[cost/energy: default: $/kWh]—(real floatingscalar)—accepted reference baseline for what the long-term deliveredaverage cost of energy (e.g., the TIS) should be at this transactivenode. In some cases, acceptable target TIS values have been found amongenergy supply costs in utilities' annual reports. Alternatively, thelowest customer costs that a utility passes along to its customers, too,might be an acceptable surrogate for the target TIS. Default: $0.05/kWh.

ΣP_(G)—[power: default: kW]—(real floating scalar)—long-term average ofthe sum of power imported into and generated within the boundaries ofthis transactive node. This parameter is a long-term average of thedenominator of the Update TIS framework function. This parameter ismostly static, but it may be updated quarterly or yearly by the owner ofthe transactive node. This parameter affects that rate at which thefunction's proportional controller tracks the infrastructure costparameter C_(I). The accuracy of this parameter is not critical. Thedefault value 1 GW should be used only as a last resort for thisparameter. This default value will virtually disable this function formost transactive nodes so that the infrastructure cost will not betracked.

α—[dimensionless]—(real floating scalar)—factor used in the proportionalcontroller to affect the rate at which the infrastructure cost parametershould track the TIS. Default value: 0.0001, assuming that updates occurevery 5 minutes.

Outputs:

C_(I)—[cost/time: default units: $/h]—Parameter defined and used inTransactive Node and Toolkit Functions and Transactive Control SystemData Collection. Time series of cost per time duration to be applied atdefined future time intervals. In this function, this output is acorrection that approximates the amortized costs of infrastructure overtime. A remedial action was initiated to disallow this output parameterfrom becoming negative.

Pseudo Code Implementation:

-   -   (1) Initialize the infrastructure cost parameter C_(I) for this        transactive node. Because this function relies on an extremely        slow, low-pass feedback loop, it is strongly recommended that        the function's infrastructure cost parameter C_(I) be        initialized to a reasonable value. If this step is not        performed, the function will eventually identify an acceptable        offset that represents infrastructure costs, but it will slowly        and asymptotically approach the offset over multiple months. The        formulation and details of this initialization may be found in        SubAppendix A.        -   Assign the initial value to the infrastructure cost            parameter as shown in Equation 1.            C _(I)=(TIS_(target)−TIS_(avg))·ΣP _(G)  (1)    -   (2) Replicate the initialized or updated infrastructure cost        parameter into the elements of the series of values expected by        the toolkit framework and publish the new series to the toolkit        framework.        -   For k=0 to K, where K=56 for certain embodiments.            -   Set C_(I)(k)=C_(I)            -   Next k            -   Publish {C_(I)(0), C_(I)(1), . . . , C_(I)(K)} to this                transactive node's toolkit framework for this function.    -   (3) After an update interval (e.g. every 5 minutes), update the        calculated infrastructure cost based on the target TIS, actual        recent TIS₀, typical sum of imported and generated power, and        parameter α. Equation (2) can be modified to disallow negative        C_(I) output parameters.        C _(I,n)=maximum(0,C _(I,n-1)+α≠(TIS_(target)−TIS_(0,n-1))·ΣP        _(G))  (2)    -   (4) Loop back to step (2).

Subappendix A: Details about Initializing and Updating InfrastructureCost Parameter C_(I)

This appendix takes one through formulations on which the initializationand updating of the infrastructure cost parameter C_(I) output of thisfunction is based.

Refer to the framework function by which the TIS for an interval iscalculated at a transactive node, copied here as Equation A1. Thenumerator is a total cost, and the denominator is the sum of electricalenergy that is imported into or generated within this transactive nodeduring interval n. The resulting division yields a unit cost of energy,the TIS, which represents the delivered cost of energy at this locationin the system.

$\begin{matrix}{{TIS}_{n} = \frac{\begin{matrix}{{\sum\limits_{a = 1}^{A}\;{{C_{E,a,n} \cdot {\hat{P}}_{G,a,n} \cdot \Delta}\; t_{n}}} +} \\{{\sum\limits_{b = 1}^{B}\;{C_{C,b,n} \cdot {\hat{P}}_{C,b,n}}} + {\sum\limits_{c = 1}^{C}\;{{C_{I,c,n} \cdot \Delta}\; t_{n}}} + {\sum\limits_{d = 1}^{D}\; C_{O,d,n}}}\end{matrix}}{\sum\limits_{a = 1}^{A}{{{\hat{P}}_{G,a,n} \cdot \Delta}\; t_{n}}}} & ({A1})\end{matrix}$

We assume that the costs in the numerator prior to applying thisfunction can be lumped together as shown in Equation A2. These costswill neither affect nor be affected by this formulation.

$\begin{matrix}{{TIS}_{n}^{old} = \frac{{Cost}_{n}^{old}}{\sum\limits_{a = 1}^{A}{{{\hat{P}}_{G,a,n} \cdot \Delta}\; t_{n}}}} & ({A2})\end{matrix}$

A term is added to both sides of Equation A2 to represent aninfrastructure cost offset that had not been represented in the priorformulation. See Equation A3. The new TIS_(target) may be thought of acorrected version of the TIS and may be independently assigned based onlong-term-average energy supply costs or other representations of thedelivered cost of energy at this system location. An infrastructure termC_(I) was selected for this function because the new infrastructurecosts will be modeled as being amortized evenly over time.

$\begin{matrix}{{TIS}_{target} = {{{TIS}_{n}^{old} + {{Infrastructure}\mspace{14mu}{Cost}\mspace{14mu}{Offset}}} = \frac{{Cost}_{n}^{old} + {{C_{I} \cdot \Delta}\; t}}{\sum\limits_{a = 1}^{A}{{{\hat{P}}_{G,a,n} \cdot \Delta}\; t_{n}}}}} & ({A3})\end{matrix}$

Equation A4 is found by subtracting Equation A2 from Equation A3.Equation A4 states a relationship between the independent referenceTIS_(target), calculated TIS values, the new infrastructure costparameter C_(I), and the sum of imported and generated power at thistransactive node.

$\begin{matrix}{{{TIS}_{target} - {TIS}_{n}^{old}} = {{{Infrastructure}\mspace{14mu}{Cost}\mspace{14mu}{Offset}} = \frac{C_{I}}{\sum\limits_{a = 1}^{A}{\hat{P}}_{G,a,n}}}} & ({A4})\end{matrix}$

We rearrange Equation A4 to solve for the new infrastructure costparameter, as shown in Equation A5.

$\begin{matrix}{C_{I} = {( {{TIS}_{target} - {TIS}_{n}^{old}} ) \cdot {\sum\limits_{a = 1}^{A}{\hat{P}}_{G,a,n}}}} & ({A5})\end{matrix}$

Equation A5 gives us insights about how to initialize the infrastructurecost parameter: Because the infrastructure cost parameter and target TISare relatively constant, they should be compared to long-term averagedrepresentations of the old TIS and sum of imported and generated power.Ideally, this node would be allowed to operate for months before thisfunction is implemented so that these “typical” values could be learned.Realistically, one may have little or no prior TIS and power values toaverage. Some off-line analysis can be performed. Regardless, any errorsduring initialization will eventually be erased by the operation of thefunction's proportional controller.

$\begin{matrix}{C_{I} = {( {{TIS}_{target} - {TIS}_{n}^{old}} ) \cdot {\sum\limits_{a = 1}^{A}{\hat{P}}_{G,a,{avg}}}}} & ({A6})\end{matrix}$

Equation A5 is also the basis for the formulation of a proportionalcontroller by which the estimated value of C_(I) may be graduallyimproved. Equation A7 suggests how C_(I) may be updated from a priorversion of itself and an approximation of the value from Equation A5.This is also illustrated in diagram 9000 of FIG. 90. The new parameter αdetermines the weight of the proportional controller and, therefore, therate of convergence. If the time between update intervals n−1 and n is 5minutes, then setting α=0.0001 will ensure a response time near a month,which is about right for the tracking of infrastructure costs. BecauseC_(I) varies extremely slowly, even longer update intervals (andcorrespondingly revised α) may be selected by implementers of thisfunction.

Equation A7 can be modified to disallow negative C_(I) output parameter.

$\begin{matrix}{C_{I,n} = {{maximum}( {0,{C_{I,{n - 1}} + {\alpha \cdot ( {{TIS}_{target} - {TIS}_{n - 1}^{old}} ) \cdot {\sum\limits_{a = 1}^{A}{\hat{P}}_{G,a,{avg}}}}}} )}} & ({A7})\end{matrix}$

It is presumed that recent calculations of the TIS (e.g., TIS_(n−1))will be available to this function at this node. However, it isrecommended that the constant, “typical,” value for the sum of importedand generated power should be used because access to this sum may not bereadily available and is not warranted by the precision used by thisfunction.

FIG. 90 is a diagram 9000 illustrating an infrastructure cost controldiagram

FIG. 91 and FIG. 92 show examples of how the infrastructure costestimate and TIS improve over time for different α parameter valuesusing the iterative approach of Equation A7 at 5-minute intervals. Inparticular, FIG. 91 shows a graph 9110 illustrating the improvement ofuninitialized infrastructure cost estimate for different α parameterselections assuming 5-minute update intervals. FIG. 92 shows a graph9120 illustrating the uninitialized correction of TIS over time fordifferent α parameter selections assuming 5-minute update intervals. Inthis instance, the TIS was 80% of the Target TIS at the time thisfunction is activated.

6.3.18 Load Function—Battery Storage—Real-Time (Function 4.1)

Description:

This function is applicable to battery storage systems that respond verydynamically to the TIS and other local conditions and provide also acontinuum of charge and discharge levels. (If the battery system hasonly a few levels of response available to it (e.g. full charge, fulldischarge, and inactive) then the implementer should select atime-of-use function to model the battery system's behavior.) Thefunction will recommend the appropriate charge and discharge rate basedon the system's power capacity, state-of-charge, and historical andpredicted incentive signals. The implementer is able to limit theresponsiveness of his system using additional preferences.

All of the load or generation by a battery system is considered elastic;none is inelastic.

An assumption is made in this present formulation that battery systeminefficiency (e.g., losses and auxiliary loads) may be ignored.

Block Input/Output Function Model:

Inputs:

-   -   {IST₀, IST₁, . . . , IST_(n), . . . , IST_(N)}—[UTC        time]—current interval start time (IST) time series.    -   {TIS₀, TIS₁, . . . , TIS_(n), . . . ,        TIS_(N−1)}—[$/kWh]—transactive incentive signal (TIS) time        series. Time series of predicted incentives.    -   SOC⁻¹—[kWh]—present state of battery charge just prior to the        prediction intervals of the current IST time series. This is the        known starting point from which battery charge should be        managed.    -   SOC_(max)—[kWh]—maximum state of charge that will be allowed for        this battery. This function will assume this constraint is        constant over time.    -   SOC_(min)—[kWh]—minimum state of charge that will be allowed for        this battery. This function will assume this constraint is        constant over time.    -   E—[kWh]—total battery energy capacity.    -   P_(c)—[kW]—nameplate rating for the rate at which the battery        system may be charged. This function will assume this constraint        is constant over time.    -   P_(d)—[kW]—nameplate rating for the rate at which the battery        system may be discharged. This function will assume this        constraint is constant over time.

Interim Calculation Products:

-   -   {Δt₀, Δt₁, . . . , Δt_(n), . . . , Δt_(N−1)}—[time:        minutes]—duration of each IST interval in the current IST time        series.    -   {SOC₀, SOC₁, . . . SOC_(n), . . . , SOC_(N−1)}—[%]—predicted        state of battery charge at the end of each IST interval using        the predicted charge and discharge profile.

Outputs:

-   -   {ΔL₁, ΔL₂, . . . , ΔL_(n), . . . , ΔL_(N−1)}—[kW]—predicted        change in elastic load for each IST interval.    -   {S₁, S₂, . . . , S_(n), . . . ,        S_(N−1)}—[dimensionless]—advisory output signal to the battery        system.

Pseudo Code Implementation:

-   -   1. Predict the power to be consumed or generated during each        current IST interval (e.g., its elastic load prediction).        -   Define state relationships for the battery system as in            equations 1 through 5. The batteries' state of charge at the            end of intervals n are its states x.

$\begin{matrix}{x = {\begin{bmatrix}x_{0} \\x_{1} \\\ldots \\x_{N - 1}\end{bmatrix} \equiv \begin{bmatrix}{SOC}_{0} \\{SOC}_{1} \\\ldots \\{SOC}_{N - 1}\end{bmatrix}}} & (1)\end{matrix}$

-   -   -   The change in state Δx is equivalent to the rate of battery            charge or discharge during the corresponding interval, which            incidentally is also the change in elastic load ΔL for the            interval. (If the change in state of charge Δx is negative,            this means that the battery system should have discharged            some of its energy during the interval. The corresponding            change in load ΔL should reduce the apparent load at this            location much as would happen if load were curtailed.            Ultimately, the correctness of the sign convention will            depend on how the outputs of this function are to be used.            If load is a generally a positive quantity, then charging of            a battery is a positive load, and discharging is a negative            load. This discussion contradicts the sign convention shown            in Equation 2, in which a negative load sign convention is            used.) The change in elastic load ΔL is an important output            from this function that is expected by the Toolkit            Framework.

$\begin{matrix}{{\Delta\; x} = {\begin{bmatrix}{\Delta\; x_{0}} \\{\Delta\; x_{1}} \\\ldots \\{\Delta\; x_{N - 1}}\end{bmatrix} \equiv \begin{bmatrix}{{- \Delta}\; L_{0}} \\{{- \Delta}\; L_{1}} \\\ldots \\{{- \Delta}\; L_{N - 1}}\end{bmatrix}}} & (2)\end{matrix}$

-   -   -   Difference equation 3 is the state relationship to which            this physical system should adhere.            Δx=A·x+b  (3)        -   where

$\begin{matrix}{{A \equiv \begin{bmatrix}\frac{1}{\Delta\; t_{0}} & 0 & \ldots & 0 \\\frac{- 1}{\Delta\; t_{1}} & \frac{1}{\Delta\; t_{1}} & \ldots & 0 \\\ldots & \ldots & \ldots & \ldots \\0 & \ldots & \frac{- 1}{\Delta\; t_{N - 1}} & \frac{1}{\Delta\; t_{N - 1}}\end{bmatrix}}{and}} & (4) \\{b \equiv {\begin{bmatrix}\frac{- {SOC}_{- 1}}{\Delta\; t_{0}} \\0 \\\ldots \\0\end{bmatrix}.}} & (5)\end{matrix}$

-   -   -   One important constraint is that the rate of charge or            discharge in each interval n should be bounded by the            physical capabilities of the conversion equipment. The            bounds are the physical nameplate ratings of the conversion            equipment.            P _(c) ≤Δx _(n) ≤P _(d)  (6)        -   The state of charge itself is often constrained at each            interval to lie within prescribed boundaries. Only a            fraction of a battery system's total energy capacity may be            available to use.            SOC_(min) ≤x _(n)≤SOC_(max)  (7)        -   The augmented cost function is the sum of incentive costs            received (and paid) at times that the battery system is            being charged or discharged. One strives to maximize this            cost function. Doing so would mean that the battery system            is doing its best to charge while incentives are low and            discharge while incentives are high in a way that will            maximize its overall incentive.            J=f ₀(x,Δt,TIS)+f ₁(x)+f ₂(x),  (8)        -   where f₀ is the main economic incentive to be maximized over            the duration that a TIS signal has been defined.

$\begin{matrix}{f_{0} = {{- {\sum\limits_{n = 0}^{N - 1}\;{\Delta\;{x_{n} \cdot {TIS}_{n} \cdot \Delta}\; t_{n}}}} = {- {\sum\limits_{n = 0}^{N - 1}{\sum\limits_{m = 0}^{M - 1}{{( {{a_{n,m} \cdot x_{m}} + b_{n}} ) \cdot {TIS}_{n} \cdot \Delta}\;{t_{n}.}}}}}}} & (9)\end{matrix}$

-   -   -   The constraints on state of charge may be incorporated via            penalty function f₁, thus avoiding the use of additional            Lagrangian terms and allowing a more direct solution            approach. This penalty function creates more accurate            solutions for successive integers k=1, 2, . . . .

$\begin{matrix}{f_{1} = {- {\sum\limits_{n = 0}^{N - 1}( \frac{( {x_{n} - {SOC}_{\max}} ) + ( {x_{n} - {SOC}_{\min}} )}{{SOC}_{\max} - {SOC}_{\min}} )^{2k}}}} & (10)\end{matrix}$

-   -   -   Similarly, the constraints on the rates of charge or            discharge may be imposed by penalty function f₂ as is shown            in equation 11. Again, this penalty function will enforce a            more accurate solution for successive integers k=1, 2, . . .            .

$\begin{matrix}{f_{2} = {{- {\sum\limits_{n = 0}^{N - 1}( \frac{( {{\Delta\; x_{n}} - P_{c}} ) + ( {{\Delta\; x_{n}} - P_{d}} )}{P_{c} - P_{d}} )^{2k}}} = {- {\sum\limits_{n = 0}^{N - 1}{\sum\limits_{m = 0}^{M - 1}( \frac{{2 \cdot ( {{a_{n,m} \cdot x_{m}} + b_{n}} )} - P_{c} - P_{d}}{P_{c} - P_{d}} )^{2k}}}}}} & (11)\end{matrix}$

-   -   -   Now that the augmented cost function J has been entirely            stated in respect to the states x, one may use the necessary            condition of equation 12 to solve for state of charge x_(n)            at the end of each interval n.

$\begin{matrix}{{\frac{\partial J}{\partial x_{n}} = 0},{{{for}\mspace{14mu} n} = 0},1,2,\ldots,{N - 1}} & (12)\end{matrix}$

-   -   -   In turn, predicted charge rate may also be calculated from            equation 3 resulting in the important predicted elastic            change in load at each interval ΔL_(n).        -   Using constraint integer k=1, equation 12 give us N            equations which may be solved for x_(n) in respect to            x_(n−1) and x_(n+1) as shown in equation 13. (The terms of b            vector have been omitted from this formulation. This general            equation 13 is set up for solution by either relaxation or            by matrix inversion, where starting and ending states are            assumed to be known. Hammerstrom has solved these equations            in MS Excel using relaxation and iterations. The solution is            somewhat soft, allowing minor violations of the stated            constraints to persist. These constraint violations could be            reduced by using larger k values or by using altogether            other, sharper penalty functions. It is easiest to assert            the final value x_(N) in this formulation. A proper            optimization would set the final state at SOC_(min),            however, which is unrealistic and undesirable. A preferred            method is to set SOC_(N) equal to starting initial value            SOC−₁, in which case the relaxation solution is fully            specified.)

$\begin{matrix}{0 = {\frac{\partial J}{\partial x_{n}} = {{- ( {{{a_{n,n} \cdot {TIS}_{n} \cdot \Delta}t_{n}} + {{a_{{n + 1},n} \cdot {TIS}_{n + 1} \cdot \Delta}t_{n + 1}}} )} - {\frac{8}{( {{SOC}_{\max} - {SOC}_{\min}} )^{2}} \cdot x_{n}} + \frac{4 \cdot ( {{SOC}_{\max} + {SOC}_{\min}} )}{( {{SOC}_{\max} - {SOC}_{\min}} )^{2}} - {\frac{8 \cdot ( {a_{n,n}^{2} + a_{{n + 1},n}^{2}} )}{( {P_{c} - P_{d}} )^{2}} \cdot x_{n}} - {\frac{8 \cdot a_{n,{n - 1}} \cdot a_{n,n}}{( {P_{c} - P_{d}} )^{2}} \cdot x_{n - 1}} - {\frac{8 \cdot a_{{n + 1},{n + 1}} \cdot a_{{n + 1},n}}{( {P_{c} - P_{d}} )^{2}} \cdot x_{n + 1}} + \frac{{4 \cdot ( {P_{d} + P_{c}} )}( {a_{n,n} + a_{{n + 1},n}} )}{( {P_{c} - P_{d}} )^{2}}}}} & (13)\end{matrix}$

-   -   2. Generate the advisory signal time series prediction for the        battery system. After the desired charge rate Δx vector has been        solved, the charge rates should be stated as changes in elastic        load ΔL_(n) at each interval n using the relationship of        equation 2. One should also state an advisory control signal S        that will be sent to the battery system. The advisory control        signal has been specified as an integer and may be calculated as        the closest integer in the assignment shown in equation 14.

$\begin{matrix}{S_{n} \equiv \{ \begin{matrix}{{{- 127} \cdot \frac{\Delta\; x_{n}}{P_{c}}},} & {{\Delta\; x_{n}} \geq 0} \\{{{- 127} \cdot \frac{\Delta\; x_{n}}{P_{d}}},} & {{\Delta\; x_{n}} < 0}\end{matrix} } & (14)\end{matrix}$

Further Alternatives:

-   -   1. Additional steps could probably be taken to make the        application of this strategy more formulaic for a specific        implementer.    -   2. A completed example would probably be useful in an appendix        to this toolkit function.    -   3. Sharper penalty functions may be used to make the solution        more accurate and which would permit fewer soft constraint        violations.    -   4. The formulation should probably be normalized. The weights of        the functions f₀, f₁, and f₂ do not enforce a true economic        optimization when the impact of f₀ may be less at times than        that of the constraint functions.    -   5. While the constraints on state of charge and charge rate have        been stated as constants, these constraints may, in fact, be        functions of time and should be thought of as an allowed        operational envelope. Letting these envelopes be more dynamic        does not break this formulation, but it does lead to the        formulation being tweaked to state constraints as functions of        time intervals n.    -   6. Implementation may wish to specify a dead zone which has not        yet been accommodated in this formulation.

6.3.19 Incentive Function—Transmission Flowgate (Function 5.1)

Description:

This function is to predict the MW flow and the cost of a transmissionflowgate for each interval start times {IST_(n)} (e.g., n=0, 1, . . . ,56) used by the toolkit framework. A transmission flowgate ispotentially congested transmission corridor defined between twotransmission zones. A flowgate may consists of one of more than moretransmission devices, such as high voltage AC/DC overhead lines and/ortransformers.

With a given network topology, generation shift factors (SF) to aspecific flowgate can be calculated by a network analysis application.Flowgates are modeled as linear inequality constraints using these shiftfactors in the Economic Dispatch (ED) Linear Programming problem. When aflowgate constraint is binding at its reliability flow limit, generatorscan be be redispatched “out-of-merit” according to their shift factorsto the flowgate, in order to relieve the congestion. Such redispatchwill lead to non-zero operational cost to a binding flowgate (aka shadowprice of a constraint in Linear Programming). The physical meaning ofthe cost of a flowgate is the cost saving with one addition MW added tothe limit of flowgate, which will increase one MW generation (cheaper)from the sending end of the flowgate and decrease one MW generation(more expensive) from the receiving end of the flowgate.

FIG. 93 is a diagram 9330 of an exemplary block input/output functionmodel, which is discussed below.

Inputs:

-   -   Predicted price of fuel, which may be either constant or a        dynamic time series, depending on the fuel.    -   Representative amortized infrastructure cost. (In some cases,        the infrastructure costs will be stated as functions of many        variables, including local costs of money, taxes, regulations,        etc.)    -   Planned generator schedule(s), such as Federal hydro schedules.    -   Constant heat rate curves of fossil generators.    -   BPA Load Forecast.    -   Historical BPA Netmom savecases, which are used to produce        generation and load profiles for any given hour of a day in a        week of a specific season.    -   WECC Flowgate definition

Outputs:

-   -   Predicted flowgate flow P_(FG,IST) For a Transmission Flowgate        FG for time series using the intervals of the current IST time        series.    -   Corresponding predicted costs of each binding Flowgate        C_(FG,IST) using the intervals of the current IST time series.        If a flowgate is not congested (non-binding) in a particular        interval, its cost will be zero.

Pseudo Code Implementation:

-   -   1. Process inputs from BPA;    -   2. Complement input data with the model data from historical        Netmom savecases and WECC heat rate curves;    -   3. Solve a multi-interval economic dispatch problem which        produces MW flow P_(FG,t) and shadow price based cost C_(FG,t)        for each flowgate FG at each scheduling interval t    -   4. Calculate P_(FG,IST) for transmission Flowgate FG and        interval IST;        -   P_(FG,IST)=P_(FG,t), where t is covers the majority portion            of an IST interval    -   5. Compute the operational cost C_(FG,IST) for each transmission        flowgate FG and each IST interval;        -   C_(FG,IST)=C_(FG,t)/T_(t)*T_(IST), where t is covers the            majority portion of an IST interval

6.3.20 Incentive Function—Equipment and Line Constraints (Function 5.2)

Description:

Discourage consumption of energy downstream from constraineddistribution equipment, including distribution lines.

Applies to transactive nodes that are in a position to mitigate theirconstraints by increasing the delivered cost of energy to downstreamtransactive nodes.

Intended to be used where constraints may be correlated to specificequipment. Does not apply to transmission flowgates.

Block Input/Output Function Model:

Inputs:

Predicted capacity to which this function applies.

Function which estimates the cost impacts of exceeding the capacityconstraint.

Outputs:

Predicted capacity cost time series C_(C) and corresponding capacitytime series P_(C).

6.3.21 Incentive Function—BPA Demand Charges (Function 7.1)

Description:

This function predicts the impact of demand charges that the BonnevillePower Administration (BPA) will apply to its customer utilitiesaccording to interpretation of its intricate Tiered Rate Methodology(TRM). The TRM explains how BPA's demand charges are to be allocated toits customer utilities at the conclusion of each month. However, sincethe transactive control and coordination system is predictive, thedemand charge impacts of the methodology should be predicted instead.This function can, at best, estimate the demand charge impacts from theTRM.

Many components of the TRM duplicate energy costs that will already berepresented in the transactive incentive signal (TIS) by electricallyupstream locations. Generally, transactive control applies energy costsat the points where electrical energy is generated and fed into theelectrical power grid. These influences should not be duplicated ordouble-counted. Therefore, this function should only insert the uniquedemand charge impacts from the TRM that apply specifically to theutilities. This may be achieved by applying upward pressure to theTIS—by adding, to the TIS computation, the product of the pair ofcapacity cost C_(C) and average power capacity P_(C)—during and around atime interval when the transactive feedback signal (TFS) predicts theoccurrence of a peak that exceeds the highest peak that has already beenrecorded during the time elapsed for the calendar month prior to thestart time (e.g., IST₀) of the TFS. If the increased TIS, in turn,applies enough downward pressure on the TFS, the predicted peak may belowered enough to prevent any additional demand charge.

Normally, an electric utility would be the entity to apply thisfunction. This function applies to a “utility” transactive node or tothe transactive node that represents the perspective of an electricutility.

Block Input/Output Function Model:

Inputs:

-   -   HLH—[number of hours]—Heavy Load Hour for every month of the        year. The daily HLH periods are defined by the North American        Electric Reliability Corporation (NERC), but should be updated        yearly or whenever there is a change.    -   C_(demand)—[$/kW]—BPA demand rate for every month for two years,        as approved by Federal Energy Regulatory Commission (FERC) and        published by BPA at the beginning of every other fiscal year        (starting in October). This is to be updated every other year in        this function or whenever there is a change.    -   CDQ—[kW]—Contract Demand Quantity for every month of the year,        as computed yearly by BPA for each of the customer/utility. This        is to be updated yearly in this function or whenever there is a        change.    -   W_(T1-HLH,m0)—[kWh]—planned Tier 1 HLH energy for the present        month m when this function is employed for the very first time;        this is an initial condition.    -   W_(T1-HLH,m+1)—[kWh]—planned Tier 1 HLH energy for the upcoming        month m+1. Since the transactive control and coordination system        provides predictions for a 4-day horizon, this should be made        available to this function at least 4 days prior to the start of        an upcoming month.    -   P_(nonFed_fix) (optional)—[kW]—monthly fixed non-Federal power        capacity that is planned by or contracted to a customer. This        may include Tier 2 power capacity, Secondary Credit Service,        Super Peak Credit, and any other energy resources that qualify        as fixed non-Federal. This is to be updated whenever there is a        change in the planned or contracted power capacity.    -   P_(nonFed_var) (optional)—[kW]— monthly variable non-Federal        power capacity that is available to a customer. An example is        small-scale renewables resources, which may be considered as        negative loads. Due to the variability of such resources, their        power outputs will have to be predicted, for each of IST        intervals, to be used in this function. P_(nonFed_var) may be        set to zero if it is small 5%) compared to P_(nonFed_fix).    -   TFS_(n)—[kW]—Transactive Feedback Signal, which is available        within the transactive node framework, where, for example, n=0,        1, . . . , 55. The TFS is only to be used when it represents the        total load for the customer's service territory. If that is not        the case, the customer should use a secondary source for the        prediction of its total utility load.    -   IST_(n)—Present time series interval start times used by the        toolkit framework, where, for example, n=0, 1, . . . , 56. (In        some embodiments, there is no prediction to correspond with        IST_(n) for n=56. This last IST is simply used to make it clear        when the final interval concludes.)    -   K—dimensionless—scaling factor (a constant) by which the effect        of the demand charge on the TIS may be scaled. This is to be set        to 1.0 until it becomes clear that it will be used.

Interim Calculation Products:

-   -   aHLH—[kW]—average monthly Tier 1 load served during the HLH of        the month.    -   P_(SCS-HLH) (optional)—[kW]—average monthly SCS load served        during the HLH of the month.    -   P_(th)—[kW]—threshold power capacity above which demand charge        may be incurred.    -   P′_(demand)—[kW]—Demand amount/capacity at a given point in a        month. This is updated every time a higher demand capacity is        recorded. At the end of the month, this should be the same as        the usual demand amount—also defined as the Demand Charge        Billing Determinant—which is used to compute the customer's        demand charge for the month.    -   A—[kWh]—average energy above P_(th) during an interval where and        surrounding where P_(C) (defined below) exceeds CSP′.

Outputs:

-   -   P_(C,n)—[kW]—average power capacity, corresponding to IST_(n).    -   C_(C,n)—[$/kW]—capacity costs, corresponding to IST_(n).

Pseudo Code Implementation:

-   -   1. Convert power capacities in units kW, if necessary.    -   2. Convert energy values in units kWh, if necessary.    -   3. Convert demand rates in units $/kW, if necessary.        -   Denote present month by m and upcoming month by m+1.    -   4. Initializations:        P′ _(demand,m)=0  (1)        P′ _(demand,m+1)=0  (2)        W _(T1-HLH,m) =W _(T1-HLH,m0)  (3)    -   5. Computations:

$\begin{matrix}{\mspace{79mu}{{aHLH}_{m} = \frac{W_{{{T\; 1} - {HLH}},m}}{{HLH}_{m}}}} & (4) \\{\mspace{79mu}{{aHLH}_{m + 1} = \frac{W_{{{T\; 1} - {HLH}},{m + 1}}}{{HLH}_{m + 1}}}} & (5) \\{P_{{th},m,n} = {{aHLH}_{m} + {CDQ}_{m} + P_{{{nonFed}\;\_\;{fix}},m} + P_{{{nonFed}\;\_\;{var}},n}}} & (6) \\{P_{{th},{m + 1},n} = {{aHLH}_{m + 1} + {CDQ}_{m + 1} + P_{{{nonFed}\;\_\;{fix}},{m + 1}} + P_{{{nonFed}\;\_\;{var}},{m + 1},n}}} & (7) \\{{{{for}\mspace{14mu} n} = 0},1,\ldots,{{55:P_{C,n}} = \{ \begin{matrix}{{\max( {0,{{TFS}_{n} - P_{{th},m,n}}} )},} & {{{if}\mspace{14mu} n} \in m} \\{\max( {0,{{TFS}_{n} - P_{{{th},{m + 1},n})}},} } & {{{if}\mspace{14mu} n} \in {m + 1}}\end{matrix} }} & (8) \\{\mspace{79mu}{{{{for}\mspace{14mu} n} \in {m:n_{{demand},m}}} = \{ {\begin{matrix}{n,} & {{{if}\mspace{14mu}{\max( P_{C,n} )}} > P_{{demand},m}} \\{Ø,} & {otherwise}\end{matrix},} }} & (9)\end{matrix}$

-   -   where Ø represents the null set.

⁢for ⁢ ⁢ n ∈ m + 1 : n demand , m = { n , if ⁢ ⁢ max ⁡ ( P C , n ) > P demand, m + 1 Ø , otherwise ( 10 ) if ⁢ ⁢ n demand , m ≠ Ø : m = { n ⁢ ⁢surrounding ⁢ ⁢ and ⁢ ⁢ including n demand , m ⁢ ⁢ ⁢ s . t . ⁢ P C , n > 0 } ⁢ if⁢⁢n demand , m + 1 ≠ Ø : m + 1 = { n ⁢ ⁢ surrounding ⁢ ⁢ and ⁢ ⁢ including ndemand , m + 1 ⁢ ⁢ s . t . ⁢ P C , n > 0 } ( 11 ) ⁢ for ⁢ ⁢ n ∈ { m ⋃ m + 1 }: A n = P C , n × ( IST n + 1 - IST n ) ( 12 ) for ⁢ ⁢ n = 0 , 1 , … , 55: C C , n = { C demand , m × ( A n ∑ i ∈ ℓ m ⁢ ⁢ A i ) × K , if ⁢ ⁢ n ∈ m Cdemand , m + 1 × ( A n ∑ i ∈ ℓ m + 1 ⁢ ⁢ A i ) × K , if ⁢ ⁢ n ∈ m + 1 0 ,otherwise ( 13 )

-   -   For the next iteration:        if P _(C,0) >P _(demand,m) :P _(demand,m) =P _(C,0)  (14)        P _(demand,m+1) =P _(C,n) _(demand,m+1)   (15)    -   6. At the start of a month:        P _(demand,m)=0  (16)        P _(demand,m+1)=0  (17)        W _(T1-HLH,m) =W _(T1-HLH,m+1)  (18)    -   7. Repeat computations under point 5.

Exaggerated Example for One Iteration at a Given Time:

-   -   FIG. 94 is a graph 9400 illustratiing an example for one        iteration at a given time.    -   n_(demand,m)=4 and n_(demand,m+1)=14 (assuming        P_(C,14)=max(P_(C,n)) for n∈m+1)    -   _(m)={2,3,4,5} and        _(m+1)={14}        P _(C,2)=TFS₂ −P _(th,m,2)        C _(C,2) =C _(demand,m)×[A ₂/(A ₂ +A ₃ +A ₄ +A ₅)]×K        P _(C,3)=TFS₃ −P _(th,m,3)        C _(C,3) =C _(demand,m)×[A ₃/(A ₂ +A ₃ +A ₄ +A ₅)]×K        P _(C,4)=TFS₄ −P _(th,m,4)        C _(C,4) =C _(demand,m)×[A ₄/(A ₂ +A ₃ +A ₄ +A ₅)]×K        P _(C,5)=TFS₅ −P _(th,m,5)        C _(C,5) =C _(demand,m)×[A ₅/(A ₂ +A ₃ +A ₄ +A ₅)]×K        P _(C,10)=TFS₁₀ −P _(th,m,10)        C _(C,10)=0        P _(C,14)=TFS₁₄ −P _(th,m+1,14)        C _(C,14) =C _(demand,m+1)×[A ₁₄ /A ₁₄]×K=C _(demand,m+1) ×K    -   For the next iteration, P_(demand,m)=0 and        P_(demand,m+1)=P_(C,14).

6.3.22 Incentive Function—BPA Demand Charges (Function 7.1.1)

Description:

An evaluation of prior function 7.1 BPA Demand Charges was carried out.This evaluation determined that the function was not recognizingmeaningful events in the presence of real load data (precisely,transactive feedback signals (TFS) data). While the inputs specified forthis present function 7.1.1 have not changed from those in function 7.1,the pseudo code algorithm has been significantly simplified and has beenshown through simulation to properly identify new demand peaks and theircost impacts.

This function predicts the impact of demand charges that the BonnevillePower Administration (BPA) will apply to its customer utilitiesaccording to interpretation of its intricate Tiered Rate Methodology(TRM). The TRM explains how BPA's demand charges are to be allocated toits customer utilities at the conclusion of each month. However, sincethe transactive control and coordination system is predictive, thedemand charge impacts of the methodology should be predicted instead.This function can, at best, estimate the demand charge impacts from theTRM.

Many components of the TRM duplicate energy costs that will already berepresented in the transactive incentive signal (TIS) by electricallyupstream locations. Generally, transactive control applies energy costsat the points where electrical energy is generated and fed into theelectrical power grid. These influences should not be duplicated ordouble-counted. Therefore, this function should only insert the uniquedemand charge impacts from the TRM that apply specifically to theutilities. This may be achieved by applying upward pressure to theTIS—by adding, to the TIS computation, the product of the pair ofcapacity cost C_(C) and incremental demand P_(C)—as the transactivefeedback signal (TFS) predicts the occurrence of a peak that exceeds thehighest peak that has already been recorded during the present calendarmonth prior to the start time (e.g., IST₀) of the TFS. If the increasedTIS, in turn, induces responsive assets to curtail load, the predictedpeak may be lowered enough to prevent any additional demand charge.

Normally, an electric utility would be the entity to apply thisfunction. This function applies to a “utility” transactive node or tothe transactive node that represents the perspective of an electricutility.

Block Input/Output Function Model:

Inputs:

-   -   HLH—[number of hours]—Heavy Load Hour for every month of the        year. The daily HLH periods are defined by the North American        Electric Reliability Corporation (NERC), but should be updated        yearly or whenever there is a change. Presently, HLH hours are        defined between 6:00 am and 10:00 pm (prevailing Pacific Time)        on days excluding Sundays and recognized holidays.    -   C_(demand)—[$/kW]—BPA demand rate for every month for two years,        as approved by Federal Energy Regulatory Commission (FERC) and        published by BPA at the beginning of every other fiscal year        (starting in October). This is to be updated every other year in        this function or whenever there is a change.    -   CDQ—[kW]—Contract Demand Quantity for every month of the year,        as computed yearly by BPA for each of the customer/utility. This        is to be updated yearly in this function or whenever there is a        change.    -   W_(T1-HLH,m0)—[kWh]—planned Tier 1 HLH energy for the present        month m when this function is employed for the very first time;        this is an initial condition.    -   W_(T1-HLH,m+1)—[kWh]—planned Tier 1 HLH energy for the upcoming        month m+1. Since the transactive control and coordination system        provides predictions for a 4-day horizon, this should be made        available to this function at least 4 days prior to the start of        an upcoming month.    -   P_(nonFed_fix) (optional)—[kW]—monthly fixed non-Federal power        capacity that is planned by or contracted to a customer. This        may include Tier 2 power capacity, Secondary Credit Service,        Super Peak Credit, and any other energy resources that qualify        as fixed non-Federal. This is to be updated whenever there is a        change in the planned or contracted power capacity.    -   P_(nonFed_var) (optional)—[kW]—monthly variable non-Federal        power capacity that is available to a customer. An example is        small-scale renewables resources, which may be considered as        negative loads. Due to the variability of such resources, their        power outputs will have to be predicted, for each of IST        intervals, to be used in this function. P_(nonFed_var) may be        set to zero if it is small (≤5%) compared to P_(nonFed_fix).    -   TFS_(n)—[kW]—Transactive Feedback Signal, which is available        within the transactive node framework, where, for example, n=0,        1, . . . , 55. The TFS is only to be used when it represents the        total load for the customer's service territory. If that is not        the case, the customer should use a secondary source for the        prediction of its total utility load.    -   IST_(n)—Present time series interval start times used by the        toolkit framework, where, for example, n=0, 1, . . . , 56.        (There is no prediction to correspond with IST_(n) for n=56.        This last IST is simply used to make it clear when the final        interval concludes.)    -   K—dimensionless—scaling factor (a constant) by which the effect        of the demand charge on the TIS may be scaled. This is to be set        to 1.0 until it becomes clear that it will be used.

Interim Calculation Products:

-   -   aHLH—[kW]—average monthly Tier 1 load served during the HLH of        the month. This value is determined by dividing a month's HLH        energy by the number of HLH hours that month.    -   P_(th)—[kW]—threshold power capacity above which demand charge        may be incurred. This value is determined as a sum of other        stated BPA threshold values.    -   P_(demand)—[kW]—Demand amount/capacity at a given point in a        month. This is updated every time a higher demand capacity is        recorded. At the end of the month, this should be the same as        the usual demand amount—also defined as the Demand Charge        Billing Determinant—which is used to compute the customer's        demand charge for the month.    -   P′_(demand)—[kW]—Like P_(demand), but refers to the predicted        future.

Outputs:

-   -   P_(C,n)—[kW]—average power capacity, corresponding to IST_(n).        This output parameter increases each time a new monthly peak        demand occurs or is predicted to occur. By the end of a month,        the sum of P_(C,1) parameters should be very close to the        determinant upon which BPA demand charges are calculated.    -   C_(C,n)—[$/kW]—capacity costs, corresponding to IST_(n). This        parameter is defined nonzero at times P_(C,n) is nonzero. The        magnitude of C_(C,n) is constant during a month, equal to the        rate that is to be charged by BPA that month for utility demand.

Pseudo Code Implementation:

-   -   a. Beginning of New Month:        -   Set m=0        -   Initialize P_(th)(ThisMonth), C_(demand)(ThisMonth),            P_(th)(NextMonth), C_(demand)(NextMonth) based on tabular            contract information from the energy supplier for the            present and next month        -   Set P_(demand)(m)=P_(th)(ThisMonth)    -   b. Beginning of Update Interval:        -   Set m=m+1    -   c. Beginning of Relaxation Update:        -   Set P′_(demand)(ThisMonth)=O_(demand)(m−1)        -   Set P′_(demand)(NextMonth)=P_(th)(NextMonth)        -   Calculate TFS_(n)(m) for n={0, 2, . . . 55}        -   For n=0 to 55

If TFS_(n)(m) > P′_(demand)(ThisMonth)  AND IST_(n)(m) is in ThisMonth AND IST_(n)(m) is within HLH hours, then   Set P_c_(n)(m) = TFS_(n)(m)− P′_(demand)(ThisMonth)   Set C_c_(n)(m) = C_(demand)(ThisMonth)   SetP′_(demand)(ThisMonth) = TFS_(n)(m) Elseif TFS_(n)(m) > P′_(demand)(NextMonth)  AND IST_(n)(m) is in NextMonth  AND IST_(n)(m) is withinHLH hours, then   Set P_c_(n)(m) = TFS_(n)(m) − P′_(demand)(NextMonth)  Set C_c_(n)(m) = C_(demand)(NextMonth)   Set P′_(demand)(NextMonth) =TFS_(n)(m) Else   Set P_c_(n)(m) = 0   Set C_c_(n)(m) = 0 Next n

-   -   d. On next relaxation update (e.g., IST₀=IST₁(m,0) does not        change, but a new calculation ID is in effect)        -   Go to (c)    -   e. On next update interval (e.g., IST₀=IST₀(m+1) will advance 5        minutes and a new calculation ID is in effect),        -   If IST₀(m) is in HLH hours, then

  Set P_(demand)(m) = maximum(P_(demand)(m−1), TFS₀(m)) Else   SetP_(demand)(m) = P_(demand)(m−1) End

-   -   -   Go to (b)

    -   f. On next month (e.g., IST₀ is in NextMonth and a new        calculation ID is in effect)        -   Go to (a)

APPENDIX A Mat lab code that implements the stated pseudo code forTKRS_7.1.1 % Note that function lnHLH(a) has been created. It returns aBoolean true % if time a is within HLH hours and is not a Sunday. Theformat of % variable “a” is presumed to be ‘yyyy-mm-ddTHH:MM:SS’.NextMonth = ThisMonth+1; % (a) Beginning of New Month PeakMonthDemand(1)= DemandThreshold(ThisMonth); P_c(1,1:56) = zeros(1,56); C_c(1,1:56) =zeros(1,56); for m = 2:length(TFS(:,1))  % (b) Beginning of UpdateInterval  if ~strcmp(IST(m,1),IST(m−1,1)) && lnHLH(IST(m−1,1)) % An update interval   PeakMonthDemand(m) = max(PeakMonthDemand(m−1), TFS(m−1,1));  else % A relaxation update   PeakMonthDemand(m) =PeakMonthDemand(m−1);  end  % (c) Beginning of Relaxation Update: PeakFutureDemand(ThisMonth) = PeakMonthDemand(m−1); PeakFutureDemand(NextMonth) = DemandThreshold(NextMonth);  % TFS wasalready read from project data  for n = 1:56 % NOTE: No distinction madeyet for month    if TFS(m,n) > PeakFutureDemand(ThisMonth) ...       &&datenum(IST(m,n),DF) >=      datenum([num2str(DemandRateYear(ThisMonth)),‘-      ’,num2str(DemandRateMonth(ThisMonth)),‘−01’]) ...       &&datenum(IST(m,n),DF) <      datenum([num2str(DemandRateYear(NextMonth)),‘-      ’,num2str(DemandRateMonth(NextMonth)),‘−01’]) ...     &&lnHLH(IST(m,n));     P_c(m,n) = TFS(m,n) − PeakFutureDemand(ThisMonth);    C_c(m,n) = DemandCharge(ThisMonth);     PeakFutureDemand(ThisMonth)= TFS(m,n);    elseif TFS(m,n) > PeakFutureDemand(NextMonth) ...      && datenum(IST(m,n),DF) >=      datenum([num2str(DemandRateYear(NextMonth)),‘-      ’,num2str(DemandRateMonth(NextMonth)),‘−01’]) ...     &&lnHLH(IST(m,n));     P_c(m,n) = TFS(m,n) − PeakFutureDemand(NextMonth);    C_c(m,n) = DemandCharge(NextMonth);     PeakFutureDemand(NextMonth)= TFS(m,n);    else     P_c(m,n) = 0;     C_c(m,n) = 0;    end  end end;************************************************************************************************* function [YorN] = lnHLH(T) %lnHLH--Logic check true if in HLH hours DT = ‘yyyy-mm-ddTHH:MM:SS’; T =datenum(T,DT) − (7 + (datenum(T,DT) > datenum(2012,11,4,10,0, 0)))/24;YorN = weekday(T) ~= 1 ...  && datevec(T)*[0 0 0 1 0 0]’ >= 6 &&datevec(T)*[0 0 0 1 0 0]’ < 22;

FIG. 95 is a diagram 9500 that shows the specified strategy during amonth.

6.3.23 Incentive Function—Seattle City Light Demand Charges (Function7.2)

Description:

This function predicts the impacts of energy and demand charges that theSeattle City Light (SCL) will apply to the University of Washington(UW). SCL supplies the UW with most of its electricity.

This function applies the impact of its energy charges to the weightedcost for the total energy imported into UW's energy territory from theTZ02 (West Washington) transmission zone transactive node. This isachieved through the addition of an “other” cost component C_(O) to thenumerator of the TIS computation at UW's transactive node.

Although the SCL's demand charges are to be allocated at the conclusionof each month, since the transactive control and coordination system ispredictive, the demand charge impacts should be predicted instead. Thisfunction can, at best, estimate the demand charge impacts. UW expects tominimize its monthly SCL demand changes by using this function to applyupward pressure to its TIS when its transactive feedback signal (TFS)predicts the occurrence of a peak in its load. This is achieved byadding the product of the pair of capacity cost C_(C) and average powercapacity P_(C) to the numerator of its TIS computation whenever its TFSexceeds the highest peak that has already been recorded during the timeelapsed for the calendar month prior to the start time (e.g., IST₀). Theproduct C_(C)·P_(C) thus represents the incremental demand charge thatUW would incur if a new peak were to happen. If the increased TIS, inturn, applies enough downward pressure on the TFS (e.g. through loadcurtailment), the predicted peak may be lowered enough to prevent anyadditional demand charge. It should be noted that, because the SCLdemand charges apply to the maximum demand during the month, the chargescan only be minimized and not completely eliminated. This function is tobe applied at UW's transactive node.

Block Input/Output Function Model:

Inputs:

-   -   C_(energy_peak)—[$/kWh]—SCL peak energy rate. This peak energy        rate is to be updated whenever there is a change. This rate        applies to energy used between six (6:00) a.m. and ten (10:00)        p.m., Monday through Saturday, excluding major holidays. (Major        holidays excluded from the peak period are New Year's Day,        Memorial Day, Independence Day, Thanksgiving Day, and Christmas        Day.) Note that Sunday is considered as part of the off-peak        period. This rate is $0.0638/kWh in one example.    -   C_(energy_offpeak)—[$/kWh]—SCL off-peak energy rate. This        off-peak energy rate is to be updated whenever there is a        change. This rate applies to energy used during times other than        the peak period. This rate is $0.0432/kWh in one example.    -   C_(demand_peak)—[$/kW]—SCL peak demand rate. This peak demand        rate is to be updated whenever there is a change. This rate        applies to kW of maximum demand P_(max_peak) during the peak        period. This rate is $0.98/kW in one example.    -   C_(demand_offpeak)—[$/kW]—SCL off-peak demand rate. This        off-peak demand rate is to be updated whenever there is a        change. This rate applies to kW of maximum demand        P_(max_offpeak) in excess of P_(max_peak) during times other        than the peak period. In other words, this off-peak demand rate        applies only if P_(max_offpeak)>P_(max_peak) and applies only to        the difference P_(max_offpeak)−P_(max_peak). This rate is        $0.26/kW in one example.    -   {P_(peak1), P_(peak2), . . . , P_(peak12)}—[kW]—monthly peak        load for every month of the most recent elapsed year. This is to        be updated at the beginning of a year if more recent data become        available.    -   K—dimensionless—scaling factor (a constant) by which the effect        of the demand charge on the TIS may be scaled. This is to be set        to 1.0 until it becomes clear that it will be used.    -   TFS_(n)—[kW]—Transactive Feedback Signal, which is available        within the transactive node framework, corresponding to the        n^(th) interval, where, for example, n=0, 1, . . . , 55. The TFS        is only to be used if it represents the total UW's demand from        SCL.    -   IST_(n)—Present time series interval start times used by the        toolkit framework. (There is no prediction to correspond with        IST₅₆. This last IST is simply used to make it clear when the        final interval concludes.)    -   TFS_(TZ02,n)—[kW]—Transactive Feedback Signal from transmission        zone transactive node TZ02, representing the average power        imported into UW's service territory during the n^(th) interval.

Interim Calculation Products:

-   -   P_(max_peak)—[kW]—Maximum demand during the peak period.    -   P_(max_offpeak)—[kW]—Maximum demand during the off-peak period.    -   h_(peak)—[number of hours]—Number of hours in one continuous        peak period.    -   h_(offpeak)—[number of hours]—Number of hours in one continuous        off-peak period.    -   δ_(peak)—[$/kWh]—Adjustment to the weighted cost of imported        energy, due to the impact of SCL energy charges, during peak        period.    -   δ_(offpeak)—[$/kWh]—Adjustment to the weighted cost of imported        energy, due to the impact of SCL energy charges, during off-peak        period.

Outputs:

-   -   C_(O,n)—[$]—Other cost representing SCL's energy charge impact,        corresponding to the n^(th) interval.    -   C_(C,n)—[$/kW]—Capacity cost corresponding to the n^(th)        interval.    -   P_(C,n)—[kW]—Average power capacity corresponding to the n^(th)        interval.

Pseudo Code Implementation:∀n,C _(O,n)=(x·δ _(peak) +y·δ _(offpeak))·TFS_(TZ02,n) ·Δt _(n)  (4)wherex=portion/fraction of n lying within

_(peak)y=portion/fraction of n lying within

_(offpeak),  (5)andΔt _(n)=IST_(n+1)−IST_(n)  (6)

-   -   1. Compute P_(c,n):        ∀n,P _(C,n)=max(0,TFS_(n) −P _(max_peak))  (7)    -   2. Compute C_(C,n):

$\begin{matrix}{{\text{∀}n},{C_{C,n} = \{ \begin{matrix}{{K \cdot ( {{x \cdot C_{demand\_ peak}} + {y \cdot C_{demand\_ offpeak}}} )},} & \begin{matrix}{{{if}\mspace{14mu}{TFS}_{n}} > P_{max\_ offpeak} >} \\P_{max\_ peak}\end{matrix} \\{{K \cdot x \cdot C_{demand\_ peak}},} & \begin{matrix}{{{if}\mspace{14mu}{TFS}_{n}} > P_{max\_ peak} \geq} \\P_{max\_ offpeak}\end{matrix} \\{0,} & {otherwise}\end{matrix} }} & (8)\end{matrix}$

-   -   -   where x and y are as defined in equation (5) above.

    -   3. For the next iteration:

$\begin{matrix}{\mspace{779mu}(9)} \\{\mspace{79mu}{P_{max\_ peak} = \{ \begin{matrix}{{TFS}_{0},} & {{{if}\mspace{14mu}( {{TFS}_{0} > P_{max\_ peak}} )}\bigcap( {n = {0 \in \ell_{peak}}} )} \\{P_{max\_ peak},} & {otherwise}\end{matrix} }} \\{\mspace{765mu}(10)} \\{P_{max\_ offpeak} = \{ \begin{matrix}{{TFS}_{0},} & {{{if}\mspace{14mu}( {{TFS}_{0} > P_{max\_ offpeak}} )}\bigcap( {n = {0 \in \ell_{offpeak}}} )} \\{P_{max\_ offpeak},} & {otherwise}\end{matrix} }\end{matrix}$

-   -   4. Repeat, starting from point 6.

Example

-   -   h_(peak)=16 h_(offpeak)=8    -   C_(energy_peak)=$0.0638/kWh C_(energy_offpeak)=$0.0432/kWh    -   δ_(peak)=$0.0069/kWh δ_(offpeak)=−$0.0137/kWh    -   δ_(demand_peak)=$0.98/kW C_(demand_offpeak)=$0.26/kW    -   K=1.0    -   P_(max_peak)=P_(max_offpeak)=min (P_(peak1), P_(peak2), . . . ,        P_(peak12))×90%=40000 kW×90%=36000 kW

Δt_(n) x y TFS_(n) TFS_(TZ02,n) TIS_(TZ02,n) C_(O,n) P_(C,n) C_(C,n)TIS_(n) n IST_(n) [h] [%] [%] [kW] [kW] [$/kWh] [$] [kW] [$/kW] [$/kWh]0 9/1/10 1/12 0 100 31225 31225 0.0569 −35.74 0 0.00 0.0432 0:00 19/1/10 1/12 0 100 31200 31200 0.0569 −35.71 0 0.00 0.0432 0:05 2 9/1/101/12 0 100 31199 31199 0.0569 −35.71 0 0.00 0.0432 0:10 3 9/1/10 1/12 0100 31192 31192 0.0569 −35.70 0 0.00 0.0432 0:15 4 9/1/10 1/12 0 10031199 31199 0.0569 −35.71 0 0.00 0.0432 0:20 5 9/1/10 1/12 0 100 3119531195 0.0569 −35.70 0 0.00 0.0432 0:25 6 9/1/10 1/12 0 100 31192 311920.0569 −35.70 0 0.00 0.0432 0:30 7 9/1/10 1/12 0 100 31090 31090 0.0569−35.58 0 0.00 0.0432 0:35 8 9/1/10 1/12 0 100 31100 31100 0.0569 −35.590 0.00 0.0432 0:40 9 9/1/10 1/12 0 100 31112 31112 0.0569 −35.61 0 0.000.0432 0:45 10 9/1/10 1/12 0 100 31090 31090 0.0569 −35.58 0 0.00 0.04320:50 11 9/1/10 1/12 0 100 31000 31000 0.0569 −35.48 0 0.00 0.0432 0:5512 9/1/10 ¼ 0 100 30960 30960 0.0569 −106.30 0 0.00 0.0432 1:00 139/1/10 ¼ 0 100 31000 31000 0.0569 −106.43 0 0.00 0.0432 1:15 14 9/1/10 ¼0 100 30936 30936 0.0569 −106.21 0 0.00 0.0432 1:30 15 9/1/10 ¼ 0 10030904 30904 0.0569 −106.10 0 0.00 0.0432 1:45 16 9/1/10 ¼ 0 100 3088030880 0.0569 −106.02 0 0.00 0.0432 2:00 17 9/1/10 ¼ 0 100 30784 307840.0569 −105.69 0 0.00 0.0432 2:15 18 9/1/10 ¼ 0 100 30880 30880 0.0569−106.02 0 0.00 0.0432 2:30 19 9/1/10 ¼ 0 100 30848 30848 0.0569 −105.910 0.00 0.0432 2:45 20 9/1/10 ¼ 0 100 30816 30816 0.0569 −105.80 0 0.000.0432 3:00 21 9/1/10 ¼ 0 100 30776 30776 0.0569 −105.66 0 0.00 0.04323:15 22 9/1/10 ¼ 0 100 30760 30760 0.0569 −105.61 0 0.00 0.0432 3:30 239/1/10 ¼ 0 100 30672 30672 0.0569 −105.31 0 0.00 0.0432 3:45 24 9/1/10 ¼0 100 30672 30672 0.0569 −105.31 0 0.00 0.0432 4:00 25 9/1/10 ¼ 0 10030768 30768 0.0569 −105.64 0 0.00 0.0432 4:15 26 9/1/10 ¼ 0 100 3076030760 0.0569 −105.61 0 0.00 0.0432 4:30 27 9/1/10 ¼ 0 100 30872 308720.0569 −105.99 0 0.00 0.0432 4:45 28 9/1/10 ¼ 0 100 31016 31016 0.0569−106.49 0 0.00 0.0432 5:00 29 9/1/10 ¼ 0 100 31584 31584 0.0569 −108.440 0.00 0.0432 5:15 30 9/1/10 ¼ 0 100 31848 31848 0.0569 −109.34 0 0.000.0432 5:30 31 9/1/10 ¼ 0 100 32072 32072 0.0569 −110.11 0 0.00 0.04325:45 32 9/1/10 1 100 0 32986 32986 0.0569 226.50 0 0.00 0.0638 6:00 339/1/10 1 100 0 34300 34300 0.0569 235.53 0 0.00 0.0638 7:00 34 9/1/10 1100 0 35476 35476 0.0569 243.60 0 0.00 0.0638 8:00 35 9/1/10 1 100 036876 36876 0.0569 253.22 876 0.98 0.0870 9:00 36 9/1/10 1 100 0 3808438084 0.0569 261.51 2084 0.98 0.1174 10:00  37 9/1/10 1 100 0 3875038750 0.0569 266.08 2750 0.98 0.1333 11:00  38 9/1/10 1 100 0 3953639536 0.0569 271.48 3536 0.98 0.1514 12:00  39 9/1/10 1 100 0 3961839618 0.0569 272.04 3618 0.98 0.1533 13:00  40 9/1/10 1 100 0 3996239962 0.0569 274.41 3962 0.98 0.1609 14:00  41 9/1/10 1 100 0 4014040140 0.0569 275.63 4140 0.98 0.1648 15:00  42 9/1/10 1 100 0 3968239682 0.0569 272.48 3682 0.98 0.1547 16:00  43 9/1/10 1 100 0 3819438194 0.0569 262.27 2194 0.98 0.1201 17:00  44 9/1/10 1 100 0 3680436804 0.0569 252.72 804 0.98 0.0852 18:00  45 9/1/10 1 100 0 35284 352840.0569 242.28 0 0.00 0.0638 19:00  46 9/1/10 1 100 0 34742 34742 0.0569238.56 0 0.00 0.0638 20:00  47 9/1/10 1 100 0 33852 33852 0.0569 232.450 0.00 0.0638 21:00  48 9/1/10 1 0 100 32612 32612 0.0569 −447.87 0 0.000.0432 22:00  49 9/1/10 1 0 100 31578 31578 0.0569 −433.67 0 0.00 0.043223:00  50 9/2/10 6 0 100 30497 30497 0.0569 −2512.98 0 0.00 0.0432 0:0051 9/2/10 6 100 0 35836 35836 0.0569 1476.46 0 0.00 0.0638 6:00 529/2/10 6 100 0 40813 40813 0.0569 1681.51 4813 0.98 0.0830 12:00  539/2/10 6 67 33 34919 34919 0.0569 0.00 0 0.00 0.0569 18:00  54 9/3/1024  67 33 36143 36143 0.0569 0.00 143 0.65 0.0570 0:00 5 9/4/10 24  6733 31816 31816 0.0569 0.00 0 0.00 0.0569 0:00

For the next iteration, P_(max_peak)=36000 kW and P_(max_offpeak)=36000kW.

In the above table, TFS_(TZ02)=TFS, but some mismatch should be expectedin reality. TIS_(TZ02) is not required as an input to this function. Itis simply being used in this example for the computation of TIS. It isshown as constant here, but is more like to have some variation inreality. TIS is neither an output of or input to this function, but isgiven in this example to show the impacts of both SCL energy and demandcharges. In certain embodiments, TIS can be computed as follows:

${TIS}_{n} = \frac{{{{TIS}_{{{TZ}\; 02},n} \cdot {TFS}_{{{TZ}\; 02},n} \cdot \Delta}\; t_{n}} + {C_{C,n} \cdot P_{C,n}} + C_{O,n}}{{{TFS}_{{{TZ}\; 02},n} \cdot \Delta}\; t_{n}}$

6.3.24 Incentive Function—Spot Market Impacts (Function 8.1)

Description:

This function is to be used by a utility that wishes to mitigate theimpacts that it will likely incur in spot markets. This functionmodifies the transactive incentive signal so that the utility'sresources may help the utility respond to its participation in the spotmarket.

Refer to FIG. 96 is a graph 9600 illustrating power operations concepts.that will be useful as some basic components of a utilities' power mixare addressed. For utilities that trade on the spot market, the cost ofprocured energy is the sum of costs from these following components:

Base load—large blocks of constant capacity that will have been procuredfar in advance of the day on which it will be used.

Term trading—procurement of coarsely shaped energy supply far in advanceof the day on which it will be used.

Pre-scheduled trading—procurement of well-shaped energy supply thatshould be settled no later than the morning before the day on which theenergy will be used.

Spot market trading—procurement of “real-time” energy needs that shouldbe settled just shortly before the beginning of the hour in which theenergy will be used. The purpose of this trading is to obtain anaccurate, final balance between forecasted load and energy resources.The energy traded on a spot market is among the most expensive energyresources in a utility's resource mix. Surplus energy may be sold in thespot market. A spot market usually addresses hourly periods, but a trendhas begun to shorten the intervals to 30 minutes or even shorter.

The transactive signals calculated at a transactive node will haveincorporated the costs and energy from base load, term, and some ofpre-scheduled energy resources that will be known from publishedschedules. However, the resources procured from “real-time” spot markettrading may not be predictable far in advance. Furthermore, thestrategies and trades may not be revealed by traders due to regulationsand the business sensitivity of this information.

This function specifies two mechanisms by which the impacts of spotmarket trading should influence the transactive incentive signal:

-   -   1. Cost of energy procured on the spot market. As for any energy        resource, the cost of energy procured on the spot market will        have an impact on the delivered cost of energy commensurate with        the fraction of total load that this energy represents. A        transactive node should predict the energy that it will procure        on the spot market and the cost of that energy. Normally, this        prediction will become more accurate as an affected hour draws        near. This effect produces energy terms C_(E) and P_(G) into the        algorithmic framework at a transactive node. Because only a        small fraction of a transactive node's forecasted load is        supplied by spot market trading, the influence of the cost of        energy procured on the spot market will also be relatively        small. (For example, if the average unit cost of other resources        is $10/MWh and the spot market unit cost is $50/MWh for 5% of        the total forecasted load, the resulting weighted unit cost is        $12/MWh.)        -   The calculation of a TIS is performed presently by summing            the costs and quantities of imported or generated energy,            not of exported or consumed energy. Therefore, the cost of            any energy that is sold (e.g., that will be exported) in a            spot market has no impact on the TIS.    -   2. An additional incentive from the utility to incentivize        responsive assets to respond to the relative cost of energy on        the spot market. From a utility's perspective, its customers        should defer energy consumption from times at which spot market        energy is expensive to times at which it is inexpensive. This        statement is true both at times that energy should be purchase        and sold on the spot market. Therefore, another incentive        component can be used to induce a utility's customers to respond        to the relative cost of energy on the spot market.        -   This incentive should create no net change in the delivered            cost of energy over long periods of time; for each hour that            it disincentivizes consumption it should create an hour            during which it incentivizes consumption to a similar            degree. Because the outcome of this incentive should be a            benefit (or cost) for an hourly block of time, this function            will assert that the infrastructure cost term C_(I) (units:            $/h) should be used to represent this incentive.

Block Input/Output Function Model:

Inputs:

-   -   {P(h₀−1), P(h₀−2), . . . , P(h₀−i), P(h₀−l)}—[kW]—historical        time series of traded capacity for recent spot market trading        hours h₀−i    -   {C(h₀−1), C(h₀−2), . . . , C(h₀−i), . . . ,        C(h₀−l)}—[$/kWh]—historical time series of unit energy cost from        prior recent prior spot market trading at hours h−1, h−2, etc.    -   {P(h₀), P(h₀+1), . . . P(h₀+1), . . . , P(h₀+l)}—[kW]—predicted        hourly capacity shortfall or surplus for each hour of the next        four days (e.g., the predicted time horizon of the transactive        signals), to the degree that such shortfalls and surpluses may        be known. Where this input cannot be known, trends will be used.        Where this input is known, it may be used to improve the        trending predictions.    -   {C(h₀), C(h₀+1), . . . , C(h₀+i), . . . ,        C(h₀+l)}—[$/kWh]—predicted hourly unit cost of energy that may        be purchased in the spot market for each hour of the next four        days (e.g., the predicted time horizon of the transactive        signals), to the degree that such shortfalls and surpluses may        be known. Where this input cannot be known, trends will be used.        Where this input is known, it may be used to improve the        trending predictions.    -   K—dimensionless—scaling parameter (a constant) by which effect        of utility incentive on C_(I) may be scaled.

Interim Calculation Products:

-   -   C_(trend,all)—[$/kWh]—average historical spot market unit energy        cost    -   |P|_(ave)—[kW]—average magnitude of historical procured (or        sold) spot market capacity    -   {C_(trend,1), C_(trend,2), . . . , C_(trend,h), . . . ,        C_(trend,24)}—[$/KWh]—trended spot market unit energy cost by        hour of day    -   {P_(trend,1), P_(trend,2), . . . , P_(trend,h), . . . ,        P_(trend,24)}—[kW]—trended procured (or sold) spot market        capacity by hour of day

Outputs:

-   -   {P_(G,0), P_(G,1), . . . , P_(G,n), . . . ,        P_(G,N)}—[kW]—predicted average power that is predicted to be        purchased or sold during each IST_(n) interval of the current        IST series. (The sign convention should apply a positive number        to sold capacity and negative number to purchased capacity.) (In        certain embodiments, there will be 56 IST intervals.)    -   {C_(E,0), C_(E,1), . . . , C_(E,n), . . . ,        C_(E,N)}—[$/kWh]—predicted unit energy cost of energy that is        predicted to be purchased or sold on the spot market during each        IST_(n) interval of the current IST series    -   {C_(I,0), C_(I,1), . . . , C_(I,n), . . . ,        C_(E,N)}—[$/h]—predicted hourly incentive applied to induce        customers to track relative spot market pricing for each        interval n.

Pseudo Code Implementation:

-   -   1. Convert available historical and predicted power capacities        into the units kW.    -   2. Convert available historical and predicted unit energy costs        into the units $/kWh.    -   3. Calculate or update the average historical spot market unit        energy cost (e.g., its trend)

$\begin{matrix}{C_{{trend},{all}} = {\frac{1}{H}{\sum\limits_{i = 1}^{H}\;{C( {h_{0} - i} )}}}} & (1)\end{matrix}$

-   -   -   C_(trend,all)—[$/kWh]—average historical spot market unit            energy cost for all hours of the day        -   H—dimensionless—total number of historic hours used in this            calculation        -   C(h₀−i)—[$/kWh]—spot market unit price of energy observed            from historic hour h₀−i.

    -   In subsequent updates, this value may be updated each hour by        applying the following filter to the prior calculation result:        (The number 168 is the number of hours in a week. This number        sets the dynamics with which the average spot market price will        be tracked.)

$\begin{matrix}{C_{{trend},{all}} = \frac{{167 \cdot C_{{trend},{all},{old}}} + {C( h_{0} )}}{168}} & (2)\end{matrix}$

-   -   -   C_(trend,all,old)—[$/kWh]—the representation of the average            spot market price that has incorporated spot market prices            prior to C(h₀). This is the prior value C_(trend,all) that            existed before this update.

    -   4. Calculate or update the average magnitude of historical spot        market capacity (e.g., its trend)

$\begin{matrix}{{P}_{ave} = {\frac{1}{H}{\sum\limits_{i = 1}^{H}\;{{P( {h_{o} - i} )}}}}} & (3)\end{matrix}$

-   -   -   |P|_(ave)—[kW]—average magnitude of historical spot market            capacity for energy that has been procured or sold for all            hours of the day        -   H—dimensionless—total number of historic hours used in this            calculation        -   |P(h₀−i)/—[kW]—magnitude of spot market capacity procured or            sold in historic hour h₀−i.

    -   In subsequent updates, this value may be updated each hour by        applying the following filter to the prior calculation result.        (The number 168 is the number of hours in a week. This number        sets the dynamics with which the average spot market capacity        purchased or sold will be tracked.):

$\begin{matrix}{{{P}_{ave} = \frac{{167 \cdot C_{{ave},{old}}} + {{P( h_{0} )}}}{168}},} & (4)\end{matrix}$

-   -   -   |P(h₀)|—[kW]—the magnitude of the next spot market capacity            to become known        -   |P|_(ave,old)—[kW]—the average spot market capacity that has            incorporated spot market capacities procured or sold prior            to |P(h₀)|.

    -   5. Calculate or update trends for hour-by-hour spot market unit        energy cost that may be used if better predictions are not        known. For each hour of the day h, estimate the recent average        spot market unit cost of energy. If a utility possesses better        means to make these predictions, then such predictions should        replace trend information as it becomes available.

$\begin{matrix}{C_{{trend},h} = {\frac{1}{D}{\sum\limits_{d = 1}^{D}\;{C_{h}( {d_{0} - d} )}}}} & (5)\end{matrix}$

-   -   -   C_(trend,h)—[$/kWh]—average spot market unit cost of energy            for the last D recent days. At least seven days should be            used.        -   D—[dimensionless]—number of days included in the average            trend        -   C_(h)(d₀−d)—[$/kWh]—the spot market unit energy price for            hour of day h recorded d days prior to the present index day            d₀.

    -   Successive updates may be accomplished using the following        filter that has a response time of about 1 week.

$\begin{matrix}{C_{{trend},h} = \frac{{6 \cdot C_{{trend},h,{old}}} + {C_{h}( d_{0} )}}{7}} & (6)\end{matrix}$

-   -   -   C_(trend,h,old)—[$/kWh]—prior value of C_(trend,h) that will            become displaced by this update.

    -   6. Calculate or update trends for hour-by-hour spot market        capacity purchased or sold that may be used if better        predictions are not known. If a utility possesses better means        to make these predictions, then such predictions should replace        trend information as it becomes available.

$\begin{matrix}{P_{{trend},h} = {\frac{1}{D}{\sum\limits_{d = 1}^{D}\;{P_{h}( {d_{0} - d} )}}}} & (7)\end{matrix}$

-   -   -   P_(trend,h)—[kW]—average spot market capacity that is            procured or sold during hour of day h in the recent history            of this transactive node.        -   D—[dimensionless]—number of days included in the average            trend        -   P_(h)(d₀−d)—[kW]— the spot market capacity procured or sold            for hour of day h recorded d days prior to the present index            day d₀.

    -   Successive updates may be accomplished using the following        filter that has a response time of about 1 week.

$\begin{matrix}{P_{{trend},h} = \frac{{6 \cdot P_{{trend},h,{old}}} + {P_{h}( h_{0} )}}{7}} & (8)\end{matrix}$

-   -   -   P_(trend,h,old)—[kW]—prior value of P_(trend,h) that will            become displaced by this update.

    -   7. Update the allocation of predicted spot market capacity to        the IST intervals and make this prediction available as an        output of this function into the transactive node's algorithmic        toolkit framework.

$\begin{matrix}\begin{matrix}{{P_{G,n} = P_{{trend},h}},} \\{{{when}\mspace{14mu}{IST}_{n}} \subseteq h} \\{{\frac{1}{b - a}{\sum\limits_{h = a}^{b}\; P_{{trend},h}}},} \\{{{when}\mspace{14mu} h} \Subset {IST}_{n}}\end{matrix} & (9)\end{matrix}$

-   -   -   P_(G,n)—[kW]—Energy term parameter output to toolkit            algorithmic framework for the interval corresponding to            interval IST_(n).

    -   8. Update the allocation of predicted spot market unit cost of        energy to the IST intervals and make this prediction available        as an output of this function into the transactive node's        algorithmic toolkit framework.

$\begin{matrix}\begin{matrix}{{C_{E,n} = C_{{trend},h}},} \\{{{when}\mspace{14mu}{IST}_{n}} \subseteq h} \\{{\frac{1}{b - a}{\sum\limits_{h = a}^{b}\; C_{{trend},h}}},} \\{{{when}\mspace{14mu} h} \Subset {IST}_{n}}\end{matrix} & (10)\end{matrix}$

-   -   -   C_(E,n)—[$/kWh]—energy cost parameter output to toolkit            algorithm is framework for the interval corresponding to            IST_(n).

    -   9. Calculate or update the additional incentive.        C _(I,h) =K·|P _(trend,all)|·(C(h)−C _(trend,all))  (11)        -   C_(I,h)—[$/h]—an incentive for future hour h. The future            time horizon should be at least as long as that of the            current IST interval set (about 4 days)        -   K—dimensionless—scaling parameter. Set this parameter to 1.0            until it becomes clear that it will be used.        -   |P_(ave,all)|—[kW]—the absolute value of the average            capacity that is traded by this utility in the spot market            based on prior history        -   C(h)—[$/kWh]—the best present prediction of the spot market            unit energy cost during future hour h. This will often have            been estimated from the trended value for this hour of the            day, but it may be replaced by better predictions, if such            prediction are available.        -   C_(ave,all)—[$/kWh]—the average spot market unit cost of            energy based on prior history.

    -   10. Allocate the incentive to IST intervals. Now that the        incentive has been predicted on an hour-by-hour basis, this        incentive should be allocated to the set of IST intervals. Two        cases should be considered. Where hour an interval IST_(n) lies        inside hour h, the incentive is simply assigned to the interval        IST_(n). However, if the interval IST_(n) is longer than an hour        and hour h lies within IST_(n), then the incentive for interval        IST_(n) should be stated as the average of the incentives for        the hours h that lie within IST_(n).

$\begin{matrix}\begin{matrix}{{C_{I,n} = C_{I,h}},} \\{{{when}\mspace{14mu}{IST}_{n}} \subseteq h} \\{{\frac{1\mspace{14mu}{hour}}{b - a}{\sum\limits_{h = a}^{b}\; C_{I,h}}},} \\{{{when}\mspace{14mu} h} \Subset {IST}_{n}}\end{matrix} & (12)\end{matrix}$

-   -   -   C_(I,n)—[$/h]—incentive to be applied during future interval            IST_(n)        -   C_(I,h)—[$/h]—hourly incentive for hour h that was            calculated in equation (X) above        -   (b−a)—[h]—number of hours included in interval IST_(n)            starting from hour a and ending hour b.

FIG. 96 is a graph 9600 illustrating power operations concepts.

6.3.25 Incentive Function—Non-Transactive Imported Energy (Function 1.1)

Description:

This function addresses the importation of electrical energy fromoutside a transactive node from entities that are not themselvestransactive nodes—are not participants in this transactive control andcoordination system. This function should be applied at transactivenodes that are scheduled to receive bulk electrical energy from outsidethe boundaries of the transactive control and coordination system. TheCalifornia-Oregon Intertie is an example of such a connection that couldpotentially import energy into a transactive control and coordinationsystem.

It is challenging to generalize this function because thenon-transactive sources of imported energy are diverse. However, theenergy predicted to flow to or from sources will typically have beenscheduled by balancing authorities and other entities that areresponsible to negotiate the flow of electrical power to and from thesources. Usually, wholesale market forces determine the cost of thescheduled energy, although such costs may not be promptly known fromindices or other records and should therefore be predicted from pasttrends. Therefore, this function is simply represented as a translationof the scheduled energy and its corresponding predicted energy costsinto the parameters of the toolkit framework.

FIG. 97 is a diagram 10700 of an exemplary block input/output functionmodel.

Pseudo Code Implementation:

-   -   1. Procure a current power exchange schedule for the exchange        that is being modeled. This schedule should predict the energy        to be exchanged for at least the next three days if it is to be        useful for the entire predicted future of transactive signals.        Some of these schedules will be found to be published daily or        even less frequently.    -   2. Procure the corresponding index or other documentation of        market price (cost) for the exchanged energy. For much of the        power exchanged in the Northwest, the price (cost) may only be        known a day later from published indices. The energy price        (cost) should therefore be predicted from trends or from an        informed simulation.    -   3. If necessary, restate the scheduled power from step #1 in        units of average power, as will be used for parameter P_(G)        (default units: average kW) in the toolkit framework.    -   4. If necessary, restate the price (cost) from step #2 in units        of unit energy cost, as will be used for parameter C_(E)        (default units; $/kWh) in the toolkit framework. (At this point        in the algorithm, the product will be useful, but it will be        stated still using the intervals from the original exchange        schedule.)    -   5. Interpolate the values C_(E)′ and P_(G)′ to recast their        intervals according to the current set of interval start times        (IST) that should have been calculated by the transactive node.        A library of interpolation functions may evolve to perform such        interpolations, but the basic approach should be to interpolate        the average power P_(G) and cost of energy included in each IST        interval C_(E) as is shown in these equations below. “Included        duration” is the part of a scheduled interval that resides        within a given IST interval.

$\begin{matrix}{P_{G} = {\frac{{total}\mspace{14mu}{energy}}{{IST}\mspace{14mu}{duration}} = \frac{\sum\limits_{{IST}\mspace{14mu}{duration}}\;{( {{included}\mspace{14mu}{duration}} )( {{scheduled}\mspace{14mu}{power}} )}}{{IST}\mspace{14mu}{duraation}}}} & ( {1.1\; a} ) \\{C_{E} = {\frac{( {{total}\mspace{14mu}{energy}\mspace{14mu}{cost}} )}{{total}\mspace{14mu}{energy}} = \frac{\begin{matrix}{\sum\limits_{{IST}\mspace{14mu}{duration}}\;{( {{scheduled}\mspace{14mu}{cost}} ) \cdot}} \\{( {{included}\mspace{14mu}{duration}} ) \cdot P_{scheduled}}\end{matrix}}{\sum\limits_{{IST}\mspace{14mu}{duration}}\;{( {{included}\mspace{14mu}{duration}} ) \cdot P_{scheduled}}}}} & ( {1.1\; b} )\end{matrix}$

P_(G)—Series of average power energy terms expected by the toolkitframework (example units: average kW). Series members correspond to ISTintervals.

C_(E)—Series of energy cost terms expected by the toolkit framework(example units: $/kWh). Series members correspond to IST intervals.

Total energy—Interim calculation of total energy that is exchanged overthe duration of a given IST interval (example units: kWh).

Included duration—The fractional part of a schedule interval that alsolies within a given IST interval (example units: seconds).

IST duration—The duration of a given IST interval (example units:seconds). In some embodiments, IST intervals are 5 minutes, 15 minutes,1 hour, 6 hours, or 1 day long.

Scheduled cost—The index or market price that corresponds to the energyexchanged during a given scheduled interval (example units: $/kWh). Thiscost may be obtained through an informed simulation based on historicaldata and trends.

Scheduled power—The average power scheduled to be exchanged during agiven schedule interval (example units: kW).

6.4 Appendix D—Example Formulation of Distributed Relative Power Flow

Introduction

Distributed control typically uses tools to assess effects of actions bydistributed calculation. The challenge has been to predict power flow toand from neighbor nodes. When generation or loads change at the presentnode, it may be impossible to allocate such change among the power flowto and from neighbors without global knowledge.

Additionally, embodiments discussed herein might have ramifications foreven centralized solvers as possible solution accelerator. Further,parallel calculations are enabled and global management of power anglebecomes unnecessary.

Further, some embodiments exhibit iterative improvement of the solutionoccurs over time.

Discussion

The example method introduced below is formulated for distributedtransactive control, where decisions are made independently atdistributed locations to respond to an incentive signal. The impacts ofthese decisions on power flow are desirably predicted, which ispresently challenging to do with conventional power flow formulations.

The example method is “relative” in that the objective of a node is tolocate itself among neighbor nodes while assuming that the vectorpositions of those nodes do not change during an iteration. In thisexample, each node considers its own vector state location to be itssystem reference.

A node does not necessarily have to know its neighbor's state. In fact,there is not necessarily any system reference by which a node could makesuch an assessment. The relative vector state of a neighbor may beadequately inferred by receiving from that neighbor its anticipatedcomplex power flow between it and the present node. It is not necessaryeven that the neighbors perfectly agree on the impedance of thetransmission corridor between them.

A node's performance using this example method may be configured toimprove over time with learning. Eventually, a node is able to test itsprediction as the predicted time (or interval) occurs and passes.

The method is an embodiment of a Newton-Raphson relaxation method. Thenumber of iterations of this method versus conventional power flowapproaches will vary from implementation to implementation.Overrelaxation and other acceleration methods may be applicable. Thepower error can be used to assess status of the solution, or can assessongoing dynamic system flux where the process is allowed to trackupdates to predicted states in “real time.”

Example Embodiment

-   -   1. Receive neighbors' predicted real and reactive flow estimates        for iteration k. Power P_(0,n) is to be exported to neighboring        node n; reactive power Q_(0,n) is to be exported to neighboring        node n. The basic node equations that will be used in the        formulation are:

$\begin{matrix}{P_{0} = {{P_{0,{Gen}} - P_{0,{Load}}} = {\sum\limits_{n = 1}^{N}\; P_{0,n}}}} & {{Eq}.\mspace{14mu} 1} \\{Q_{0} = {{Q_{0,{Gen}} - Q_{0,{Load}}} = {\sum\limits_{n = 1}^{N}\; Q_{0,n}}}} & {{Eq}.\mspace{14mu} 2}\end{matrix}$

-   -   2. Calculate the real and reactive power errors based on        neighbors' estimated real and reactive power exchange that they        have provided and any updated estimates of generation and load        at this node:

$\begin{matrix}{{{\Delta\; P_{0}} \doteq {P_{0,{Gen}} - P_{0,{Load}}}} = {\sum\limits_{n = 1}^{N}\; P_{0,n}}} & {{Eq}.\mspace{14mu} 3} \\{{{\Delta\; Q_{0}} \doteq {Q_{0,{Gen}} - Q_{0,{Load}}}} = {\sum\limits_{n = 1}^{N}\; Q_{0,n}}} & {{Eq}.\mspace{14mu} 4}\end{matrix}$

-   -   3. Use real and reactive flow and knowledge of corridor        impedance to solve for and update the voltages and relative        angles of each neighbor. Use the best present estimate of this        node's voltage V₀ for this iteration k and the power P_(0,n) and        reactive power Q_(0,n) reported by interacting neighbor nodes.        Note that the voltages and power angles of neighboring nodes are        inferred from their reports of how much real and reactive power        they intend to import or export. Neighbors need not perfectly        agree on their relative voltages and angles in order for this        approach to work. As derived in the appendix:

$\begin{matrix}{V_{n} = \frac{( {V_{0} - \frac{Q_{0,n}X_{0,n}}{V_{0}}} )}{\cos( {\tan^{- 1}( \frac{P_{0,n}X_{0,n}}{V_{0}^{2} - {Q_{0,n}X_{0,n}}} )} )}} & {{Eq}.\mspace{11mu} 5} \\{{\delta_{0} - \delta_{n}} = {\tan^{- 1}( \frac{P_{0,n}X_{0,n}}{V_{0}^{2} - {Q_{0,n}X_{0,n}}} )}} & {{Eq}.\mspace{11mu} 6}\end{matrix}$

-   -   4. Update Jacobian elements for this node's voltage and angle        using the updated state variables from this iteration k. The        state variables are the relative angles between this node and        its neighbors, the voltages of neighbor nodes, and the voltage        of this node. For this formulation, one can assume values of        δ_(n) and V_(n) are held constant during the iteration. Such        differentials can be calculated that will allow expansion of the        power errors in terms of the voltage and angle of this node        only, as will be accomplished in the next steps.

$\begin{matrix}{\frac{dP}{{dV}_{0}} = {\sum\limits_{n = 1}^{N}\;{\frac{V_{n}}{X_{0,n}}{\sin( {\delta_{0} - \delta_{n}} )}}}} & {{Eq}.\mspace{11mu} 7} \\{\frac{dP}{d\;\delta_{0}} = {\sum\limits_{n = 1}^{N}\;{\frac{V_{0}V_{n}}{X_{0,n}}{\cos( {\delta_{0} - \delta_{n}} )}}}} & {{Eq}.\mspace{11mu} 8} \\{\frac{dQ}{{dV}_{0}} = {\sum\limits_{n = 1}^{N}\;{\frac{1}{X_{0,n}}\lbrack {{2\; V_{0}} - {V_{n}{\cos( {\delta_{0} - \delta_{n}} )}}} \rbrack}}} & {{Eq}.\mspace{11mu} 9} \\{\frac{dQ}{d\;\delta_{0}} = {\sum\limits_{n = 1}^{N}{\frac{V_{0}V_{n}}{X_{0,n}}{\sin( {\delta_{0} - \delta_{n}} )}}}} & {{Eq}.\mspace{11mu} 10}\end{matrix}$

-   -   -   Derivations of Eqs. 7-8 can be found in the appendix. Note            that the values calculated for Eq. 8 and Eq. 9 are much            larger and more influential than those calculated in Eq. 7            and Eq. 10. Consequently, the calculation can be accelerated            by using only these two components, thus decoupling the real            and reactive components of power flow. Alternatively, the            system can be established to manage only real power or only            reactive power (separate control mechanisms).

    -   5. Calculate voltage change and angle change of this node only.        These two unknowns are solvable from power and reactive power        equations and a first linear expansion with respect to changes        in the voltage ΔV₀ and angle Δδ₀. Because this is a relative        formulation, a solution is found for the new conditions of this        node that will solve the real and reactive power errors. The        result will be an updated voltage for this node. The angle will        later be discarded and is not a state (the angle of this node is        defined as the reference), but the resulting angle help us        allocate changes in power flow among the powers being exchanged        with neighbors.

$\begin{matrix}{{\Delta\; P} = {{\sum\limits_{n = 1}^{N}\;\frac{{dP}_{0,n}}{d\;\delta_{0}}} - {\Delta\;\delta_{0}} + \frac{{dP}_{0,n}}{d\; V_{0}} - {\Delta\; V_{0}}}} & {{Eq}.\mspace{11mu} 11}\end{matrix}$

-   -   -   By substitution:

$\begin{matrix}{{\Delta\; P} = {{\sum\limits_{n = 1}^{N}{\frac{V_{0}V_{n}}{X_{0,n}}{{\cos( {\delta_{0} - \delta_{n}} )} \cdot \Delta}\;\delta_{0}}} + {\sum\limits_{n = 1}^{N}\;{\frac{V_{n}}{X_{0,n}}{{\sin( {\delta_{0} - \delta_{n}} )} \cdot \Delta}\; V_{0}}}}} & {{Eq}.\mspace{11mu} 12} \\{\mspace{79mu}{{\Delta\; Q} = {{\sum\limits_{n = 1}^{N}{{\frac{d\; Q_{0,n}}{d\;\delta_{0}} \cdot \Delta}\;\delta_{0}}} + {\sum\limits_{n = 1}^{N}{{\frac{d\; Q_{0,n}}{d\; V_{0}} \cdot \Delta}\; V_{0}}}}}} & {{Eq}.\mspace{11mu} 13}\end{matrix}$

-   -   -   By substitution:

$\begin{matrix}{{\Delta\; Q} = {{\sum\limits_{n = 1}^{N}{\frac{V_{0}V_{n}}{X_{0,n}}{{\sin( {\delta_{0} - \delta_{n}} )} \cdot \Delta}\;\delta_{0}}} + {\sum\limits_{n = 1}^{N}{{{\frac{1}{X_{0,n}}\lbrack {{2V_{0}} - {V_{n}{\cos( {\delta_{0} - \delta_{n}} )}}} \rbrack} \cdot \Delta}\; V_{0}}}}} & {{Eq}.\mspace{11mu} 14}\end{matrix}$

-   -   -   Finish updating the state variables at this node using the            changes that were calculated using Eq. 12 and Eq. 14.            δ₀(k+1)=δ₀(k)+Δδ₀  Eq. 15            V ₀(k+1)=V ₀(k)+ΔV ₀  Eq. 16

    -   6. Use the updated voltage state and temporary angle for this        node to calculate refine the estimate of real and reactive power        to be exchanged with neighbors. (The change in angle may be used        to modify the relative angle states, but doing so is not        necessary.)

$\begin{matrix}{{P_{0,n}( {k + 1} )} = {\frac{{V_{0}( {k + 1} )}{V_{n}(k)}}{X_{0,n}}{\sin( {{\delta_{0}( {k + 1} )} - {\delta_{n}(k)}} )}}} & {{Eq}.\mspace{11mu} 17} \\{{Q_{o,n}( {k + 1} )} = {\frac{V_{0}( {k + 1} )}{X_{0,n}}\lbrack {{V_{0}( {k + 1} )} - {{V_{n}(k)}{{cos\delta}_{0}( {k + 1} )}} - {\delta_{n}(k)}} \rbrack}} & {{Eq}.\mspace{11mu} 18}\end{matrix}$

-   -   7. Provide these updated estimates of real and reactive power to        be exchanged with neighbors to those neighbors for their use        with iteration k+1, (the values calculated in step 6 are those        that will be shared with neighbors during iteration k+l.)    -   8. Reset this node's angle to zero.        δ₀=0  Eq. 19    -   9. Calculate the real and reactive power errors given the        updated state. This power error may be used for confidence        assessments and convergence criteria. (See steps 4 and 5.)

$\begin{matrix}{{\Delta\; P_{0}} = {{P_{0,{Gen}}( {k + 1} )} - {P_{0,{Load}}( {k + 1} )} - {\sum\limits_{n = 1}^{N}\;{P_{0,n}( {k + 1} )}}}} & {{Eq}.\mspace{11mu} 20} \\{{\Delta\; Q_{0}} = {{Q_{0,{Gen}}( {k + 1} )} - {Q_{0,{Load}}( {k + 1} )} - {\sum\limits_{n = 1}^{N}\;{Q_{0,n}( {k + 1} )}}}} & {{Eq}.\mspace{11mu} 21}\end{matrix}$

-   -   10. Repeat. If the process is repeated using the same neighbors'        estimates of real and reactive power, this node's voltage may be        further resolved. If the process is repeated using newly updated        neighbors' estimates of real and reactive power for iteration        k+1, the entire system power flow solution becomes refined by        iteration.

Examples

The approach can be demonstrated using a simple example where a nodeinteracts with only two neighbors and must assess its relative powerflow state from information reported by these two neighbors. Let thisnode have no real or reactive generation or load. One possible flowstate having small power error is shown in diagram 9800 of FIG. 99.

In step 1, assume that a perturbation has occurred at node 2 and itreports 1.2+j1.0 should now be leaving the center node. Node 1 reportsan unchanged complex power flow of 1.0+j1.0.

In step 2, the new power error is calculated to be −0.2 because therenow appears to be 0.2 more real power leaving this node than enteringit.

In step 3, the voltage and angle of node 2 is corrected to match thecomplex power that is reported to the present node by node 2. This isillustrated in diagram 9900 of FIG. 99.

In step 4, the present variability of power is assessed based on thestate determined in step 3.

$\begin{matrix}{\frac{dP}{d\;\delta_{0}} = 19.9994} & {\frac{dP}{d\; V_{0}} = 0.1999} \\{\frac{dQ}{d\;\delta_{0}} = 0.1999} & {\frac{dQ}{d\; V_{0}} = 20.0006}\end{matrix}$

In step 5, solve for the corresponding changes of this node's voltageand angle that will help resolve the power error. The voltage and angleof this node are updated accordingly.Δδ₀=−0.0100 radians=0.573° ΔV ₀=0.001

In step 6, real and reactive power to be exchanged with neighbor nodesis recalculated using the new voltage and angle for the present node.The implications of this calculation are shown in diagram 10000 of FIG.100. The voltage and angle of the present node have been altered, whichhas changed also the real and reactive power that would be exchanged bythis node with nodes 1 and 2. The resulting power is balanced partwaybetween the powers that had been reported by nodes 1 and 2 at thebeginning of the iteration. The reactive power is unfortunatelydecreased by about 1%, an outcome of the nonlinearity of thecalculation.

Interestingly, the result of fast decoupled calculations at this nodewould have been resulted in about the same result.

APPENDIX

1. Real and reactive power flow between this and neighbor node:

Apparent power:S=VI*  Eq. A1

Voltage at this node is defined as V₀·e^(jδ) ⁰ . Current leaving thisnode is defined as

$\frac{{V_{0} \cdot e^{j\;\delta_{0}}} - {V_{n} \cdot e^{j\;\delta_{n}}}}{{jX}_{0,n}},$where a common practice has been adopted of representing the impedancebetween the nodes by the reactance component only.

By substitution of these values into Eq. AI.,

$\begin{matrix}{\overset{\_}{S} = {j{{\frac{V_{0}}{X_{0,n}}\lbrack {V_{0} - {V_{n} \cdot e^{j{({\delta_{0} - \delta_{n}})}}}} \rbrack}.}}} & {{Eq}.\mspace{11mu}{A2}}\end{matrix}$

Real power leaving this node to node n is the real part of the apparentpower:

$\begin{matrix}{{P_{0,n} \equiv {{Re}\{ \overset{\_}{S} \}}} = {\frac{V_{0}V_{n}}{X_{0,n}}{\sin( {\delta_{0} - \delta_{n}} )}}} & {{Eq}.\mspace{11mu}{A3}}\end{matrix}$

Reactive power leaving this node to node n is the imaginary component ofthe apparent power:

$\begin{matrix}{{Q_{0,n} \equiv {{Im}\{ \overset{\_}{S} \}}} = {\frac{V_{0}}{X_{0,n}}\lbrack {V_{0} - {V_{n}{\cos( {\delta_{0} - \delta_{n}} )}}} \rbrack}} & {{Eq}.\mspace{11mu}{A4}}\end{matrix}$

2. Given power and reactive power, calculate neighbor's voltage andrelative angle.

The reactive power equation can be used to solve for neighbor's voltageand relative angle. First solve Eq. A4 for V_(n) with respect to therelative angle.

$\begin{matrix}{V_{n} = \frac{( {V_{0} - \frac{Q_{0,n}X_{0,n}}{V_{0}}} )}{\cos( {\delta_{0} - \delta_{n}} )}} & {{Eq}.\mspace{11mu}{A5}}\end{matrix}$

By substitution of V_(n) into Eq. A3, the relative angle may becalculated in terms of known variables.

$\begin{matrix}{{\delta_{0} - \delta_{n}} = {\tan^{- 1}( \frac{P_{0,n}X_{0,n}}{V_{0}^{2} - {Q_{0,n}X_{0,n}}} )}} & {{Eq}.\mspace{11mu}{A6}}\end{matrix}$

And by substitution of the relative angle of Eq. A6 into Eq. A5,one cansolve for V_(n) also in terms of known variables:

$\begin{matrix}{V_{n} = \frac{( {V_{0} - \frac{Q_{0,n}X_{0,n}}{V_{0}}} )}{\cos( {\tan^{- 1}( \frac{P_{0,n}X_{0,n}}{V_{0}^{2} - {Q_{0,n}X_{0,n}}} )} )}} & {{Eq}.\mspace{11mu}{A7}}\end{matrix}$

3. Jacobian sensitivities of power at this node to changes in thisnode's voltage and relative angles:

Differentiate Eq. A3 for every neighbor node n with respect to V₀ andwith respect to the relative power angle δ₀−δ_(n) to get Eq. A8 and Eq.A9:

$\begin{matrix}{\frac{{dP}_{0,n}}{{dV}_{0}} = {\sum\limits_{n = 1}^{N}\;{\frac{V_{n}}{X_{0,n}}{\sin( {\delta_{0} - \delta_{n}} )}}}} & {{Eq}.\mspace{11mu}{A8}} \\{\frac{{dP}_{0,n}}{d( {\delta_{0} - \delta_{n}} )} = {\sum\limits_{n = 1}^{N}\;{\frac{V_{0}V_{n}}{X_{0,n}}{\cos( {\delta_{0} - \delta_{n}} )}}}} & {{Eq}.\mspace{11mu}{A9}}\end{matrix}$

This formulation will assume that δ_(n) remains constant through thisiteration. Solving with respect to this node's angle,

$\begin{matrix}{\frac{{dP}_{0,n}}{d\;\delta_{0}} = {\sum\limits_{n = 1}^{N}\;{\frac{V_{0}V_{n}}{X_{0,n}}{{\cos( {\delta_{0} - \delta_{n}} )}.}}}} & {{Eq}.\mspace{11mu}{A10}}\end{matrix}$

4. Jacobian sensitivities of reactive power at this node to changes inthis node's voltage and relative angles:

Similar to what was done above, differentiate Eq. A4 for every neighbornode n with respect to V₀ and with respect to the relative power angleδ₀−δ_(n) to get Eq. A11 and Eq. A12:

$\begin{matrix}{\frac{{dQ}_{0,n}}{{dV}_{0}} = {\sum\limits_{n = 1}^{N}{\frac{1}{X_{0,n}}\lbrack {{2\; V_{0}} - {V_{n}{\cos( {\delta_{0} - \delta_{n}} )}}} \rbrack}}} & {{Eq}.\mspace{11mu}{A11}} \\{\frac{{dQ}_{0,n}}{d( {\delta_{0} - \delta_{n}} )} = {\sum\limits_{n = 1}^{N}\;{\frac{V_{0}V_{n}}{X_{0,n}}{\sin( {\delta_{0} - \delta_{n}} )}}}} & {{Eq}.\mspace{11mu}{A12}}\end{matrix}$

Remembering that δ_(n) remains constant through this iteration andsolving with respect to this node's angle,

$\begin{matrix}{\frac{{dQ}_{0,n}}{d\;\delta_{0}} = {\sum\limits_{n = 1}^{N}\;{\frac{V_{0}V_{n}}{X_{0,n}}{{\sin( {\delta_{0} - \delta_{n}} )}.}}}} & {{Eq}.\mspace{11mu}{A13}}\end{matrix}$

5. Power and reactive power error definitions:

$\begin{matrix}{{\Delta\; P} = {P_{Gen} - P_{Load} - {\sum\limits_{n = 1}^{N}P_{0,n}}}} & {{Eq}.\mspace{11mu}{A14}} \\{{\Delta\; Q} = {Q_{Gen} - Q_{Load} - {\sum\limits_{n = 1}^{N}Q_{0,n}}}} & {{Eq}.\mspace{11mu}{A15}}\end{matrix}$

6. Calculate voltage and angle of this node.

In a traditional power flow calculation, linear expansion would becompleted about all power angle and voltage states. For example,

$\begin{matrix}{{\Delta\; P} = {{\sum\limits_{n = 1}^{N}{\frac{{dP}_{0,n}}{d( {\delta_{0} - {\delta\; n}} )} \cdot {\Delta( {\delta_{n} - \delta_{0}} )}}} + {\sum\limits_{n = 1}^{N}{{\frac{{dP}_{0,n}}{{dV}_{0}} \cdot \Delta}\; V_{0}}} + {\sum\limits_{n = 1}^{N}{{\frac{{dP}_{0,n}}{{dV}_{n}} \cdot \Delta}\;{V_{n}.}}}}} & {{Eq}.\mspace{11mu}{A16}}\end{matrix}$

In the present, relative formulation, assume δ_(n) and V_(n) areconstant through each iteration at this node. Eq. A16 can be simplifiedto

$\begin{matrix}{{\Delta\; P} = {{\sum\limits_{n = 1}^{N}{{\frac{{dP}_{0,n}}{d\;\delta_{0}} \cdot \Delta}\;\delta_{0}}} + {\sum\limits_{n = 1}^{N}{{\frac{{dP}_{0,n}}{{dV}_{0}} \cdot \Delta}\;{V_{0}.}}}}} & {{Eq}.\mspace{11mu}{A17}}\end{matrix}$

Remembering Eq. A8 and Eq. A1D, by substitution,

$\begin{matrix}{{\Delta\; P} = {{\sum\limits_{n = 1}^{N}{\frac{V_{0}V_{n}}{X_{0,n}}{{\cos( {\delta_{0} - \delta_{n}} )} \cdot \Delta}\;\delta_{0}}} + {\sum\limits_{n = 1}^{N}{\frac{V_{n}}{X_{0,n}}{{\sin( {\delta_{0} - \delta_{n}} )} \cdot \Delta}\;{V_{0}.}}}}} & {{Eq}.\mspace{11mu}{A18}}\end{matrix}$

Similarly, for Q, a traditional linearization might result in

$\begin{matrix}{{\Delta\; Q} = {{\sum\limits_{n = 1}^{N}{\frac{{dQ}_{0,n}}{d( {\delta_{0} - \delta_{n}} )} \cdot {\Delta( {\delta_{0} - \delta_{n}} )}}} + {\sum\limits_{n = 1}^{N}{{\frac{{dQ}_{0,n}}{{dV}_{0}} \cdot \Delta}\; V_{0}}} + {\sum\limits_{n = 1}^{N}{{\frac{{dQ}_{0,n}}{{dV}_{n}} \cdot \Delta}\;{V_{n}.}}}}} & {{Eq}.\mspace{11mu}{A19}}\end{matrix}$

In the present, relative formulation, assume δ_(n) and V_(n) areconstant through each iteration at this node. Eq. A19 can be simplifiedto

$\begin{matrix}{{{\Delta\; Q} = {{\sum\limits_{n = 1}^{N}{\frac{{dQ}_{0,n}}{d\;\delta_{0}} \cdot {\Delta\delta}_{0}}} + {\sum\limits_{n = 1}^{N}{{\frac{{dQ}_{0,n}}{{dV}_{0}} \cdot \Delta}\; V_{0}}}}},} & {{Eq}.\mspace{11mu}{A20}}\end{matrix}$

Remembering Eq. A1l and Eq. A13, by substitution,

$\begin{matrix}{{\Delta\; Q} = {{\sum\limits_{n = 1}^{N}{\frac{V_{0}V_{n}}{X_{0,n}}{{\sin( {\delta_{0} - \delta_{n}} )} \cdot \Delta}\;\delta_{0}}} + {\sum\limits_{n = 1}^{N}{{{\frac{1}{X_{0,n}}\lbrack {{2\; V_{0}} - {V_{n}{\cos( {\delta_{0} - \delta_{n}} )}}} \rbrack} \cdot \Delta}\;{V_{0}.}}}}} & {{Eq}.\mspace{11mu}{A21}}\end{matrix}$

7 CONCLUDING REMARKS

Having illustrated and described the principles of the disclosedtechnology, it will be apparent to those skilled in the art that thedisclosed embodiments can be modified in arrangement and detail withoutdeparting from such principles. For example, any one or more aspects ofthe disclosed technology can be applied in other embodiments. In view ofthe many possible embodiments to which the principles of the disclosedtechnologies can be applied, it should be recognized that theillustrated embodiments are only preferred examples of the technologiesand should not be taken as limiting the scope of the invention.

What is claimed is:
 1. A system for distributing electricity,comprising: a plurality of transactive nodes, each transactive nodebeing associated with one or more electric resources, one or moreelectric loads, or a combination of one or more electric resources andone or more electric loads; and a network connected to the transactivenodes to facilitate communication between the transactive nodes, thetransactive nodes being configured to exchange incentive and feedbacksignals with one another in order to determine an electrical demand inthe system for a current time interval and to provide an electricalsupply sufficient to meet the electrical demand for the current timeinterval; wherein the transactive nodes are further configured toexchange incentive and feedback signals for two or more future timeintervals in addition to the incentive and feedback signals for thecurrent time interval; and wherein the two or more future time intervalshave increasingly coarser granularity.
 2. The system of claim 1),wherein the current time interval is the time interval that is next tooccur and be coordinated by the system.
 3. The system of claim 1),wherein at least one of the transactive nodes modifies one or both ofits incentive or feedback signals in response to previously receivedincentive and feedback signals.
 4. The system of claim 3), wherein theat least one of the transactive nodes is associated with an elasticload, and wherein the modified incentive or feedback signals correspondsto a predicted change in the elastic load.
 5. The system of claim 3),wherein the at least one of the transactive nodes is associated with anelectrical resource, and wherein the modified incentive or feedbacksignals corresponds to a change in the electrical resource.
 6. Thesystem of claim 3), wherein the at least one of the transactive nodes isassociated with an electrical resource, and wherein the modifiedincentive signals correspond to a change in local conditions.
 7. Thesystem of claim 1), wherein one or more of the transactive nodes computetheir respective incentive and feedback signals using functions selectedfrom a library of functions.
 8. The system of claim 1), wherein theincentive and feedback signals further include confidence level dataindicating a respective reliability of the incentive and feedbacksignals.
 9. A system for distributing electricity, comprising: aplurality of transactive nodes, each transactive node being associatedwith one or more electric resources, one or more electric loads, or acombination of one or more electric resources and one or more electricloads; and a network connected to the transactive nodes and facilitatingcommunication between the transactive nodes, the transactive nodes beingconfigured to exchange sets of signals with one another in order todetermine an electrical demand in the system for a current time intervaland to provide an electrical supply sufficient to meet the electricaldemand for the current time interval, each set of signals includingsignals for determining the electric loads and supplies for the currenttime interval as well as signals for determining the electric loads andsupplies for two or more future time intervals; wherein the future timeintervals have increasingly longer durations as the time intervals arefarther into the future relative to the current time interval.
 10. Thesystem of claim 9), wherein the current time interval corresponds to animminent time interval that is next to occur in the system.
 11. Thesystem of claim 9), wherein the transactive nodes are configured toupdate the values of the sets of signals at an update frequency, theupdate frequency corresponding to a duration of the current timeinterval.
 12. The system of claim 9), wherein the transactive nodes areconfigured to exchange the set of signals with one another iterativelyover time such that the signals for a respective time interval stabilizeas the respective time interval approaches the current time interval.13. The system of claim 9), wherein the transactive nodes are configuredto exchange the set of signals with one another on an asynchronousevent-driven basis or a clock-driven basis.
 14. The system of claim 9),wherein a respective set of the transactive nodes are configured toiteratively exchange a set of signals with one another until theexchanged set of signals converges to within an acceptable degree oftolerance.
 15. The system of claim 9), wherein a transactive node in therespective set of the transactive nodes is further configured totransmit an updated set of signals when local conditions at thetransactive node cause the updated set of signals to deviate from apreviously transmitted set of signals beyond a relaxation criterion. 16.The system of claim 9), wherein the sets of signals further includeconfidence level data indicating a respective reliability of theexchanged signals.
 17. A system for distributing electricity,comprising: a plurality of transactive nodes, each transactive nodebeing associated with one or more electric supplies, one or moreelectric loads, or a combination of one or more electric supplies andone or more electric loads; and a network connected to the transactivenodes and facilitating communication between the transactive nodes, thetransactive nodes being configured to exchange sets of signals with oneanother in order to determine an electrical demand in the system for acurrent time interval and to provide an electrical supply sufficient tomeet the electrical demand for the current time interval, a respectiveone of the transactive nodes being configured to compute its incentiveand feedback signals using one or more functions selected from a libraryof functions; wherein, through the use of the one or more functions, therespective one of the transactive nodes computes a control signalselected from a set of signed whole numbers and communicates thecomputed control signal to one or more loads, resources, or loads andresources associated with the respective one of the transactive nodes.18. The system of claim 17), wherein the one or more functions selectedfrom the library of functions are selected based on the type and numberof electrical supplies and electrical loads with which the respectivetransactive node is associated.
 19. The system of claim 17), wherein theone or more functions include one or more load functions, one or moreresource functions, or a combination of one or more load functions andresource functions.
 20. The system of claim 17), wherein the one or morefunctions are selected from a group of resource functions comprising oneor more of: (a) a resource function adapted to account for importedelectrical energy, (b) a resource function adapted to account for arenewable energy resource, (c) a resource function adapted to accountfor fossil fuel generation; (d) a resource function adapted to accountfor general infrastructure cost; (e) a resource function adapted toaccount for system constraints; (f) a resource function adapted toaccount for system energy losses; (g) a resource function adapted toaccount for demand charges; (h) a resource function adapted to accountfor market impacts.
 21. The system of claim 17), wherein the one or morefunctions are selected from a group of load functions comprising one ormore of: (a) a load function adapted to account for a bulk inelasticload, (b) a load function adapted to account for an event-driven demandresponse; (c) a load function adapted to account for a time-of-usedemand response; (d) a load function adapted to account for a real-timecontinuum demand response.
 22. The system of claim 17), wherein therespective one of the transactive nodes controls one or more elasticloads and adjusts the one or more elastic loads in response to thefeedback and incentive signals received at the respective one of thetransactive nodes.
 23. The system of claim 17), wherein the one or morefunctions are implemented by individual software modules that can becombined with one another to implement a desired transactor behavior forthe respective one of the transactive nodes.
 24. The system of claim17), wherein the computed control signal is interpreted by an electricalgenerator or set of electrical generators as a fraction of thegenerator's or generators' rated generation capacity.
 25. The system ofclaim 17), wherein the computed control signal is interpreted by anelectrical load or set of electrical loads as a fraction of the load'sor loads' rated power.
 26. A system for distributing electricity,comprising: a plurality of transactive nodes, each transactive nodebeing associated with one or more electric resources, one or moreelectric loads, or a combination of one or more electric resources andone or more electric loads; and a network connected to the transactivenodes and facilitating communication between the transactive nodes; thetransactive nodes being configured to exchange sets of signals with oneanother in order to determine an electrical demand in the system for acurrent time interval and to provide an electrical supply sufficient tomeet the electrical demand for the current time interval; each set ofsignals including signals for determining the electric loads andsupplies for the current time interval as well as signals fordetermining the electric loads and supplies for two or more future timeintervals; wherein a transactive node in the respective set of thetransactive nodes is further configured to transmit an updated set ofsignals when local conditions at the transactive node cause the updatedset of signals to deviate from a previously transmitted set of signalsbeyond a relaxation criterion.
 27. The system of claim 26), wherein thecurrent time interval corresponds to an imminent time interval that isnext to occur in the system.
 28. The system of claim 26), wherein thetransactive nodes are configured to update the values of the sets ofsignals at an update frequency, the update frequency corresponding to aduration of the current time interval.
 29. The system of claim 26),wherein the transactive nodes are configured to exchange the set ofsignals with one another iteratively over time such that the signals fora respective time interval stabilize as the respective time intervalapproaches the current time interval.
 30. The system of claim 26),wherein the transactive nodes are configured to exchange the set ofsignals with one another on an asynchronous event-driven basis or aclock-driven basis.
 31. The system of claim 26), wherein a respectiveset of the transactive nodes are configured to iteratively exchange aset of signals with one another until the exchanged set of signalsconverges to within an acceptable degree of tolerance.
 32. The system ofclaim 26), wherein the sets of signals further include confidence leveldata indicating a respective reliability of the exchanged signals.